Autoconf - Autoconf

Не путать с Автоконфигурация.
Autoconf
Heckert GNU white.svg
Оригинальный автор (ы)Дэвид Маккензи
Разработчики)Проект GNU
изначальный выпуск1991
Стабильный выпуск
2.69 / 24 апреля 2012 г.; 8 лет назад (2012-04-24)
Репозиторий
Отредактируйте это в Викиданных
Операционная системаКроссплатформенность
ТипИнструмент программирования
ЛицензияGNU GPL
Интернет сайтwww.gnu.org/программного обеспечения/ autoconf/

GNU Autoconf инструмент для производства настроить скрипты для создания, установки и упаковки программного обеспечения в компьютерных системах, где Оболочка Борна доступен.

Autoconf не зависит от используемых языков программирования, но часто используется для проектов, использующих C, C ++, Фортран, Фортран 77, Erlang или Цель-C.

Сценарий configure настраивает программный пакет для установка на конкретной целевой системе. После выполнения серии тестов в целевой системе сценарий настройки генерирует файлы заголовков и makefile из шаблонов, таким образом настраивая программный пакет для целевой системы. Вместе с Automake и Libtool, Autoconf формирует Система сборки GNU, который включает несколько других инструментов, в частности Autoheader.

Обзор использования

Блок-схема autoconf и автопроизводитель. Обратите внимание, что в ранних версиях autoconf файл configure.ac назывался configure.in.

Разработчик указывает желаемое поведение скрипта настройки, записывая список инструкций в GNU m4 язык в файле "configure.ac". Библиотека предопределенных m4 макросы доступен для описания общих инструкций сценария настройки. Autoconf преобразует инструкции в "configure.ac" в переносимый сценарий конфигурации. Система, которая будет выполнять сборку, не должна иметь установленного autoconf: autoconf необходим только для сборки сценария конфигурации, который обычно поставляется с программным обеспечением.

История

Autoconf был основан летом 1991 года Дэвидом Маккензи для поддержки его работы в Фонд свободного программного обеспечения. В последующие годы она расширилась, включив в нее улучшения от различных авторов, и стала наиболее широко используемой системой конфигурации сборки для написания переносимых бесплатных или программное обеспечение с открытым исходным кодом.

Подход

Autoconf похож на пакет Metaconfig, используемый Perl. В я делаю система, ранее использовавшаяся X Window System (до X11R6.9) тесно связан, но имеет другую философию.

Подход Autoconf к переносимость это проверить на Особенности, не для версии. Например, собственный компилятор C в SunOS 4 не поддерживает ISO C. Однако пользователь или администратор может установить компилятор, совместимый с ISO C. Подход, основанный исключительно на версиях, не обнаружит присутствие компилятора ISO C, но подход с тестированием функций сможет обнаружить компилятор ISO C, установленный пользователем. Обоснование этого подхода заключается в получении следующих преимуществ:

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

Autoconf предоставляет обширную документацию о непереносимости многих конструкций оболочки POSIX на более старые оболочки и ошибки в них. Он также предоставляет M4SH, замену синтаксиса оболочки на основе макросов.[1]

Критика

Существует некоторая критика, утверждающая, что Autoconf использует устаревшие технологии, имеет множество устаревших ограничений и излишне усложняет простые сценарии для автора configure.ac скрипты. В частности, часто упоминаемыми слабыми местами Autoconf являются:

  • Общая сложность используемой архитектуры, в большинстве проектов используется многократное повторение.[2][3]
  • Сгенерированный 'configure' записывается в Оболочка Борна и поэтому создание Makefile происходит медленно.
  • Некоторые люди думают, что скрипты configure, сгенерированные autoconf, предоставляют только управляемый вручную интерфейс командной строки без какой-либо стандартизации.[4] Хотя это правда, что некоторые разработчики не соблюдают общие соглашения, такие соглашения существуют и широко используются.[5]
  • M4 необычен и неизвестен многим разработчикам. Разработчикам нужно будет изучить его, чтобы расширить autoconf с помощью нестандартных проверок.[4][6]
  • Для слабой обратной и прямой совместимости требуется сценарий-оболочка.[7]
  • Скрипты, созданные Autoconf, обычно большие и довольно сложные. Несмотря на то, что они производят обширное ведение журнала, их отладка может быть сложной.

Из-за этих ограничений несколько проектов, в которых использовалась система сборки GNU, перешли на другие системы сборки, такие как CMake и SCons.[2][8]

Смотрите также

использованная литература

  1. ^ «Портативный снаряд». Autoconf. Получено 20 января 2020.
  2. ^ а б Нойндорф, Александр (21.06.2006). «Почему проект KDE перешел на CMake - и как».
  3. ^ Камп, Поул-Хеннинг (15 августа 2012 г.). «Поколение, потерянное на базаре». Очередь ACM. 10 (8).
  4. ^ а б Макколл, Эндрю (21.06.2003). «Остановите безумие autoconf! Зачем нам нужна новая система сборки».
  5. ^ «Стандарты кодирования GNU».
  6. ^ Камп, Поул-Хеннинг (20 апреля 2010 г.). "Ты позвонил им автокреп инструменты?". Архивировано из оригинал на 2017-09-11. Получено 2017-08-16.
  7. ^ Дики, Томас. "почему я до сих пор использую autoconf 2.13".
  8. ^ «Архивная копия». Архивировано из оригинал на 2008-12-02. Получено 2009-06-10.CS1 maint: заархивированная копия как заголовок (ссылка на сайт)

внешняя ссылка