Почему GNU binutils и GDB были объединены в один пакет?
Смотрите, особенно, теги раздел.
Каково было обоснование этого решения? Влияет ли слияние на предложенный способ сборки последних версий binutils и GDB? (На самом деле, когда я проверил binutils-2_25_1 и побежал make all && make install, Я получил gdb также.)
Решение
Я сделал преобразование. Причина, по которой я сделал их объединенным хранилищем, была отчасти исторической и отчасти практической.
Исторически GDB и binutils почти всегда были вместе. Они находились в одном дереве источников (называемом «дево»), когда их поддерживали внутри Лебедя. Затем, позже, когда был создан sourceware.org, они использовали общий репозиторий (называемый «src»). Вы, возможно, не заметили этого, потому что хранилище использовало модули CVS, чтобы позволить разработчикам проверять только часть дерева.
Практически, GDB и binutils разделяют много кода. Они делятся своей инфраструктурой сборки (configure и тому подобное); они разделяют библиотеки поддержки ( libiberty а также include) каталоги; они делятся библиотекой BFD; и они делятся библиотекой кодов операций. Для меня было больше смысла хранить их вместе, чтобы избежать постоянного слияния назад и вперед (это уже сделано для некоторых компонентов с GCC, и это реальная боль), а также попытаться минимизировать проблемы, когда изменения в одном проекте негативно влияет на других. Например, по крайней мере теоретически люди, занимающиеся регулярной разработкой на BFD, должны собрать оба gdb а также Binutils.
Верхний уровень configure скрипт, используемый общим репозиторием, позволяет разработчику отключить любой конкретный каталог, используя --disable-DIR, Например, если вы не хотите создавать GDB, передайте --disable-gdb,
Другие решения
Других решений пока нет …