☰

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

tag-icon • tag-icon compiling programming
Являются ли automake и autoconf стандартным способом компиляции кода?

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

./configure
make
sudo make install

Но недавно я наткнулся на программу ./autogen.sh, которая генерирует для меня скрипты конфигурации и создания, а также выполняет их.

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

решение1

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подготовят исходный код для распространения и проверят, что результатом является полный пакет исходного кода
  • и так далее...

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

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

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

решение2

В этой области есть два «крупных игрока»: Cmake и GNU Autotools.

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

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

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

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

решение3

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

решение4

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

Связанный контент