Является ли automake и autoconf стандартным способом компиляции кода?

Я иногда компилирую приложения из исходного кода и использую:

./configure
make
sudo make install

Но недавно я наткнулся на то, ./autogen.shчто генерирует скрипты configure и make для меня и выполняет их.

Какие существуют другие методы для упрощения компиляции C / C ++ / C # (моно)? Сделать кажется немного старым. Есть ли новые инструменты там? Учитывая выбор, какой я должен использовать?

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 представит новую функцию, например, системный вызов «send», и позже другие операционные системы примут его. Вместо спагетти кода, который проверял бренды и версии, разработчики начали исследовать возможности, поэтому код стал:

#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, которую вы видели ранее.

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

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

-

Automake также выросла из существующих практик в сообществе. Проект GNU стандартизировал обычный набор целей для Makefiles:

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

Создание совместимых make-файлов стало обременительным, потому что было много шаблонов, которые повторялись снова и снова. Таким образом, Automake был новым компилятором, который интегрировался с autoconf и обрабатывал «исходный» Makefile (названный Makefile.am) в Makefile, который затем можно было передавать в Autoconf.

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

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

В этой области есть два "Больших игрока"; Cmake и GNU Autotools.

• GNU Autotools - это способ работы GNU, и он сосредоточен на * nix. Это своего рода система мета-сборки, предоставляющая набор инструментов, которые генерируют конкретную конфигурацию и создают файлы для того, что вы пытаетесь сделать. Это помогает вам вносить больше изменений в ваш код без необходимости напрямую манипулировать вашей системой сборки, а также помогает другим создавать ваш код способами, для которых вы не проектировали - под * nix.

• Cmake - это кроссплатформенный способ делать вещи. Команда Cmake создает программное обеспечение многими разными способами, включая GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux и т. Д. Если вы вообще обеспокоены переносимостью вашей кодовой базы, это путь.

Как уже упоминалось, некоторые люди, кажется, любят Scons. Если вы знакомы с Python, это может обеспечить большую согласованность в вашей рабочей среде.

Ruby также имеет своего рода систему мета-сборки под названием Rake, которая сама по себе довольно крута и очень удобна для тех, кто уже знаком с Ruby.

Scons является одной из возможных замен, хотя у меня нет личного опыта. Это также реализовано в Python, что может быть проблемой, в зависимости от среды сборки.

Если вы используете C # / Mono, вы можете использовать msbuild (файлы .sln / .csproj, используемые MonoDevelop и Visual Studio) для управления всем процессом сборки.

Затем вы можете либо собрать из MonoDevelop, либо запустить xbuildкоманду в своем любимом терминале (лучше всего работает в Mono> = 2.6). Это чрезвычайно просто и практически не требует никаких действий с вашей стороны, потому что MonoDevelop будет обрабатывать файлы msbuild для вас, и вам не нужно будет редактировать их, если вы не хотите настроить что-то большее, чем может сделать пользовательский интерфейс MonoDevelop.

Я не знаком с тем, как люди, зависящие от msbuild, обрабатывают установки для своих проектов, но вы всегда можете спросить об этом. ;-)

Для C # вы можете использовать xbuild (и msbuild для windows), который соберет проект из файлов вашего проекта.