Автоделают и autoconf стандартный способ скомпилировать код?

Autoconf и Automake были изложены для решения эволюционной проблемы Unix.

Как Unix, развитый из различных направлений, разработчики, которые хотели портативный код, были склонны писать код как это:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Поскольку Unix был разветвлен в различные реализации (BSD, SystemV, много ветвлений поставщика, и более позднего Linux и другие подобные Unix системы), это стало важным для разработчиков, которые хотели написать портативный код для написания кода, который зависел не от конкретного бренда операционной системы, а на функциях, выставленных операционной системой. Это важно, потому что версия Unix представила бы новую возможность, например, "отправить" системный вызов, и позже другие операционные системы примут его. Вместо того, чтобы иметь спагетти кода, который проверил на бренды и версии, разработчики, начали зондировать функциями, таким образом, код стал:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

Большинство файлов README для компиляции исходного кода назад в 90-х указало на разработчиков, чтобы отредактировать config.h файл и прокомментировать это надлежащие функции, доступные в системе, или поставит стандарт config.h файлы для каждой конфигурации операционной системы, которая была протестирована.

Этот процесс был и громоздким и подверженным ошибкам, и это - то, как Autoconf оказался. Необходимо думать о Autoconf как о языке, составленном из команд оболочки со специальными макросами, которые смогли заменить человеческий процесс редактирования config.h с инструментом, который зондировал операционную систему для функциональности.

Вы обычно писали бы свой код зондирования в файле configure.ac и затем выполняли бы команду autoconf, которая скомпилирует этот файл в исполняемую команду настройки, которую Вы видели используемый.

Таким образом, когда Вы работаете ./configure && make Вы зондировали для функций, доступных в Вашей системе, и затем создавали исполняемый файл с конфигурацией, которая была обнаружена.

Когда проекты с открытым исходным кодом начали использовать системы управления исходным кодом, имело смысл регистрироваться в configure.ac файле, но не результат компиляции (настраивают). autogen.sh является просто маленьким сценарием, который вызывает autoconf компилятор с правильными аргументами команды для Вас.

--

Автосделайте вырос также из существующих методов в сообществе. Проект GNU стандартизировал регулярный набор целей для Make-файлов:

• make all разработал бы проект
• make clean удалил бы все скомпилированные файлы из проекта
• make install установил бы программное обеспечение
• вещи как make dist и make distcheck подготовил бы источник к распределению и проверил бы, что результатом был полный пакет исходного кода
• и так далее...

Создание совместимых make-файлов стало обременительным, потому что было много шаблона, который был повторен много раз. Поэтому Автосделайте, был новый компилятор, который интегрировался с autoconf и обработал "исходный" Make-файл (названный Makefile.am) в Make-файлы, которые могли затем питаться к Автоконференции.

automake/autoconf набор инструментальных средств на самом деле использует много других инструментов помощника, и они увеличиваются другими компонентами для других определенных задач. Поскольку сложность выполнения этих команд в порядке выросла, потребность в готовом-к-управляемому сценарии родилась, и это - то, куда autogen.sh прибыл из.

Насколько я знаю о, Gnome был проектом, который представил использование этого сценария помощника autogen.sh