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

22

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

./configure
make
sudo make install

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

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

Луи Салин
источник
нет ничего лучше, чем просто «код». Например, если вы получаете код Java, вы, вероятно, создадите его, используя maven или ant, если вы получаете Python, то хорошим выбором будет setuptools. Не существует стандартных способов что-либо скомпилировать. Может быть, вам следует переформулировать вопрос.
Diega
Хорошая точка зрения. Я на самом деле кодирую в C # с моно, но мой вопрос относится и к C / C ++.
Луи Салин
Небольшое примечание: autogen.sh не выполняет make для вас, просто настройте.
Сэнди
@Sandy autogen.sh- это в основном пользовательские сценарии, которые обычно вызывают, autoreconfно также могут вызывать ./configureи даже make. Я не думаю, что его поведение стандартизировано каким-либо образом; главная цель состоит в том, чтобы иметь исполняемый файл в проекте, который люди могут запускать (вместо того, чтобы знать, что им нужно колдовать autoreconf)
umläute

Ответы:

42

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

miguel.de.icaza
источник
Просто небольшая проза: стандарты GNU требуют, чтобы сгенерированные файлы отправлялись в виде tarballs, чтобы уменьшить зависимости сборки до минимума универсально доступных инструментов. Если вы получаете исходный код (например, из системы контроля версий), сгенерированные файлы не будут там.
vonbrand
14

В этой области есть два "Больших игрока"; 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.

Эли Фрей
источник
6

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

tsvallender
источник
2
Портативность не проблема, так как Python теперь практически везде. Пока что основная претензия к SCons заключается в том, что она неприемлемо медленная. Есть некоторые хитрости, чтобы жертвовать точностью сборки в пользу скорости, но я не уверен, что она все еще на одном уровне с Make.
Алекс Б
3

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

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

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

Сэнди
источник
Да, я знаю о xbuild, но я пытаюсь отучить себя от IDE, которые просто хотят держать меня за руку. Кроме того, Mono скомпилирован с использованием Mono и использует autoconf, поэтому я хотел бы узнать немного больше. Благодарность!
Луи Салин
1
Интересно, что многие проекты Mono пытаются перейти на msbuild сейчас, когда xbuild работает так хорошо. Это делает поддержку Windows / Mac немного проще. Mono имеет так много C-кода, что я не уверен, насколько практично было бы для них перейти на xbuild. Но autoconf прекрасно работает, поэтому делайте все, что работает для вас. :-)
Сэнди
0

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


источник