GNU Autoconf - это инструмент для создания сценариев конфигурации для сборки, установки и упаковки программного обеспечения в компьютерных системах, где доступна оболочка Bourne .
Автор (ы) оригинала | Дэвид Маккензи |
---|---|
Разработчики) | Проект GNU |
Первый выпуск | 1991 г. |
Стабильный выпуск | 2.71 / 28 января 2021 г . [1] |
Репозиторий | |
Написано в | Perl |
Операционная система | Кроссплатформенность |
Тип | Инструмент программирования |
Лицензия | GNU GPL |
Веб-сайт | www |
Autoconf не зависит от используемых языков программирования, но часто используется для проектов, использующих C , C ++ , Fortran , Fortran 77, Erlang или Objective-C .
Сценарий configure настраивает программный пакет для установки в конкретной целевой системе. После выполнения серии тестов в целевой системе сценарий configure генерирует файлы заголовков и make-файл из шаблонов, таким образом настраивая программный пакет для целевой системы. Вместе с Automake и Libtool Autoconf образует систему сборки GNU , которая включает в себя несколько других инструментов, в частности Autoheader.
Обзор использования
Разработчик указывает желаемое поведение скрипта настройки, записывая список инструкций на языке GNU m4 в файл с именем «configure.ac». Доступна библиотека предопределенных макросов m4 для описания общих инструкций сценария настройки. Autoconf преобразует инструкции в "configure.ac" в переносимый сценарий конфигурации. В системе, которая будет выполнять сборку, не обязательно должен быть установлен autoconf: autoconf нужен только для сборки скрипта configure, который обычно поставляется вместе с программным обеспечением.
История
Autoconf был основан летом 1991 года Дэвидом Маккензи для поддержки его работы в Free Software Foundation . В последующие годы в нее были включены улучшения от различных авторов, и она стала наиболее широко используемой системой конфигурации сборки для написания переносимого бесплатного программного обеспечения или программного обеспечения с открытым исходным кодом .
Подход
Autoconf похож на пакет Metaconfig, используемый Perl . Система imake , ранее использовавшаяся системой X Window (до X11R6.9), тесно связана, но имеет другую философию.
Подход Autoconf к переносимости заключается в проверке функций , а не версий . Например, родной C компилятор на SunOS 4 не поддерживает ISO C . Однако пользователь или администратор может установить компилятор, совместимый с ISO C. Подход, основанный исключительно на версиях, не обнаружит наличия компилятора ISO C, но подход тестирования функций сможет обнаружить компилятор ISO C, установленный пользователем. Обоснованием этого подхода является получение следующих преимуществ:
- сценарий настройки может получить разумные результаты в новых или неизвестных системах
- это позволяет администраторам настраивать свои машины и использовать скрипт настройки для использования этих настроек.
- нет необходимости отслеживать мельчайшие детали версий, номеров патчей и т. д., чтобы выяснить, поддерживается ли конкретная функция или нет
Autoconf предоставляет обширную документацию о непереносимости многих конструкций оболочки POSIX на более старые оболочки и ошибки в них. Он также предоставляет M4SH, замену синтаксиса оболочки на основе макросов. [2]
Критика
Существует некоторая критика в отношении того, что Autoconf использует устаревшие технологии, имеет множество устаревших ограничений и излишне усложняет простые сценарии для автора сценариев configure.ac . В частности, часто упоминаемыми слабыми сторонами Autoconf являются:
- Общая сложность используемой архитектуры, в большинстве проектов используется многократное повторение. [3] [4]
- Сгенерированный файл configure записывается в оболочке Bourne, поэтому создание файла Makefile происходит медленно.
- Некоторые люди думают, что скрипты configure, сгенерированные autoconf, предоставляют только управляемый вручную интерфейс командной строки без какой-либо стандартизации. [5] Хотя это правда, что некоторые разработчики не соблюдают общие соглашения, такие соглашения существуют и широко используются. [6]
- M4 необычен и неизвестен многим разработчикам. Разработчикам нужно будет изучить его, чтобы расширить autoconf с помощью нестандартных проверок. [5] [7]
- Для слабой обратной и прямой совместимости требуется сценарий-оболочка. [8]
- Скрипты, сгенерированные Autoconf, обычно большие и довольно сложные. Несмотря на то, что они производят обширное ведение журнала, их отладка может быть сложной.
Из-за этих ограничений несколько проектов, в которых использовалась система сборки GNU, перешли на другие системы сборки, такие как CMake и SCons . [3] [9]
Смотрите также
Рекомендации
- ^ "autoconf-2.71 выпущен [стабильный]" . Архивы autoconf . Источник 2021-01-29 .
- ^ «Переносная оболочка» . Autoconf . Проверено 20 января 2020 года .
- ^ а б Нойндорф, Александр (21.06.2006). «Почему проект KDE перешел на CMake - и как» .
- ^ Камп, Поул-Хеннинг (15 августа 2012 г.). «Поколение, потерянное на базаре» . Очередь ACM . 10 (8): 20–23. DOI : 10.1145 / 2346916.2349257 . S2CID 11656592 .
- ^ а б Макколл, Эндрю (21.06.2003). «Остановите безумие autoconf! Зачем нам нужна новая система сборки» .
- ^ «Стандарты кодирования GNU» .
- ^ Камп, Поул-Хеннинг (20 апреля 2010 г.). "Вы называете их инструментами для автозахвата ?" . Архивировано из оригинала на 2017-09-11 . Проверено 16 августа 2017 .
- ^ Дики, Томас. «почему я до сих пор использую autoconf 2.13» .
- ^ «Архивная копия» . Архивировано из оригинала на 2008-12-02 . Проверено 10 июня 2009 .CS1 maint: заархивированная копия как заголовок ( ссылка )
Внешние ссылки
- Официальный веб-сайт
- Архив макросов GNU Autoconf
- Домашняя страница Goat Book (также известная как Autobook)
- Использование Automake и Autoconf с C ++
- Использование библиотек C / C ++ с Automake и Autoconf .
- Домашняя страница Autotoolset
- Autotools: руководство по Autoconf, Automake и Libtool для практиков.
- Автоинструменты Mythbuster