Autoconf linux что это

Autoconf linux что это

Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of M4 macro calls.

Producing configuration scripts using Autoconf requires GNU M4. You should install GNU M4 (at least version 1.4.6, although 1.4.13 or later is recommended) before configuring Autoconf, so that Autoconf’s configure script can find it. The configuration scripts produced by Autoconf are self-contained, so their users do not need to have Autoconf (or GNU M4).

Downloading Autoconf

GNU Autoconf releases can be found on http://ftp.gnu.org/gnu/autoconf/ [via http] and ftp://ftp.gnu.org/gnu/autoconf/ [via FTP]. It can also be found on one of our FTP mirrors. Please use a mirror if possible.

Third party macros can be downloaded from the Autoconf Macro Archive.

Alpha/beta releases of Autoconf can be found in https://alpha.gnu.org/pub/gnu/autoconf/, and the latest development sources for Autoconf can always be fetched through git, using either of:

You can also view the git tree on the web.

DO NOT use Autoconf sources from these locations for production use.

Documentation

Autoconf documentation can be found in several formats at http://www.gnu.org/software/autoconf/manual/. You may also find more information about Autoconf by looking at your local documentation. For example, you might try looking in /usr/share/doc/autoconf/, or use info autoconf at the shell prompt.

Mailing Lists

Autoconf has several moderated mailing lists, each with an archive.

For general Autoconf discussions, use (archives).

Development of Autoconf, and GNU in general, is a volunteer effort, and your contribution would be welcome. For general information, please read How to help GNU. If you’d like to get involved with Autoconf, it’s a good idea to join this general list.

If you have a patch for a bug in Autoconf that hasn’t yet been fixed in the latest git sources of Autoconf, please send the patch (made for the current git sources, not the released sources) to (archives).

All commits to the repository are automatically mailed to (archives and subscription).

You can subscribe to any GNU mailing list via the web as described below. Or you can send an empty mail with a Subject: header line of just «subscribe» to the relevant -request list. For example, to subscribe yourself to the bug-autoconf list, you would send mail to with no body and a Subject: header line of just «subscribe».

Announcements

The low-volume mailing list autotools-announce contains all announcements about Autoconf and a few other related projects. Important announcements about Autoconf and most other GNU Software in general are also made on the info-gnu list.

Related Software

Autoconf is often used together with the following software systems:

• GNU M4 is a prerequisite for Autoconf.
• Perl is a prerequisite for Autoconf.
• GNU Automake uses Autoconf.
• GNU Libtool also uses Autoconf.

Report a Bug

If you think you have found a bug in GNU Autoconf, then please post as complete a report as possible to the Autoconf bug tracker on Savannah. Mail to is also accepted, but currently causes extra work for the maintainers. An easy way to collect all the required information, such as platform and compiler, is to run make check, and include the resulting file tests/testsuite.log to your report. Disagreements between the manual and the code are also bugs.

Maintainers

GNU Autoconf is maintained by several developers, including Paul Eggert and Eric Blake . Contributors, and consolidated development information, are listed on the Savannah page.

Autoconf Humor

For a more light-hearted look at Autoconf, you may be interested in these alternate renderings of prior versions of this web page.

You may also be interested in this bug report, asking why Autoconf bothers to mark generated scripts as readable.

“The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom. We defend the rights of all software users.”

Please send general FSF & GNU inquiries to . There are also other ways to contact the FSF. Broken links and other corrections or suggestions can be sent to .

Please see the Translations README for information on coordinating and submitting translations of this article.

Copyright © 1998-2020 Free Software Foundation, Inc.

Источник

Autoconf linux что это

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Электронные книги по ОС Linux

Linux From Scratch (version 6.8)
Назад	Глава 6. Установка программ базовой системы	Вперед

6.34. Пакет Autoconf-2.68

В пакете Autoconf находятся программы создания скриптов командной оболочки, которые могут автоматически конфигурировать исходный код.

Приблизительное время сборки: 4,8 SBU

Требуемое дисковое пространство: 12,4 MB

6.34.1. Установка пакета Autoconf

Подготовьте пакет Autoconf для компиляции:

Чтобы проверить результаты, наберите:

На это потребуется продолжительное время, приблизительно 4,7 SBU. Кроме того, будут пропущены 6 тестов, в которых используется Automake. Для выполнения полного набора тестов, пакет Autoconf следует протестировать снова, после того, как будет установлен пакет Automake.

6.34.2. Описание пакета Autoconf

Установленные программы: autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate и ifnames

Установленные директории: /usr/share/autoconf

Создает скрипты командной оболочки, которые автоматически конфигурируют пакеты с исходным кодом так, чтобы их можно было использовать в Unix-подобных системах различного вида. Эти конфигурационные скрипты, которые он создает, являются независимыми – их запуск не требует программы autoconf

Инструмент для создания файлов шаблонов с инструкциями #define языка С, используемыми для конфигурирования

Команда-обвертка (wrapper) для макропроцессора M4

Автоматически в правильном порядке запускает utoconf, autoheader, aclocal, automake, gettextize и libtoolize с тем, чтобы сохранить время, когда в файлах шаблонов autoconf и automake делаются изменения

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

GNU Autoconf

Autoconf

Разработчики:	проект GNU
Написана на:	Perl, m4
Операционная система:	кросс-платформенное программное обеспечение
Тип ПО:	инструментальное программное обеспечение
Лицензия:	GNU General Public License
Веб-сайт	www .gnu .org /software /autoconf /autoconf .html

Autoconf — это утилита для создания скриптов командного процессора, которые автоматически конфигурируют пакеты с исходным кодом так, чтобы они могли работать на множестве UNIX-подобных систем.

Содержание

Пакет Autoconf служит двум основным целям:

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

Параметры

Скрипты конфигурации, созданные Autoconf, при работе не требуют вмешательства пользователя; обычно они даже не требуют, чтобы были заданы аргументы, указывающие тип системы. Вместо этого, такие скрипты тестируют наличие каждого средства, которое может понадобиться данному пакету. В ходе выполнения каждой из проверок, скрипты печатают отчёт о проводимых проверках. Таким образом эти скрипты хорошо справляются с системами, которые являются гибридами или специализированными вариантами большинства видов UNIX. Таким образом, пропадает необходимость в сопровождении файлов со списком всех возможностей всех версий каждого варианта UNIX.

Для каждого пакета программного обеспечения, который использует Autoconf, из шаблона создаётся скрипт настройки, который перечисляет системные возможности, в которых нуждается данный пакет или которые он может использовать. После того, как код на языке командного процессора, распознающий и обрабатывающий ту или иную возможность, написан, Autoconf позволяет использовать этот код во всех пакетах, которые могут использовать (или нуждаются) в соответствующей возможности. Если позже по каким-то причинам понадобится изменить код командного процессора, то изменения необходимо будет внести только в одно место; все скрипты настройки могут быть автоматически пересозданы, чтобы отразить изменения кода.

Существует несколько разных задач, относящихся к созданию переносимого программного обеспечения, которые в настоящее время нельзя решить средствами Autoconf. Среди них — автоматическое создание файлов Makefile со всеми необходимыми стандартными целями, а также предоставление замены стандартных библиотечных функций и заголовочных файлов в тех системах, в которых эти функции или файлы отсутствуют. Однако работа в этом направлении ведётся и эти возможности могут появиться в будущих версиях.

Autoconf навязывает некоторые ограничения на имена макросов, которые используются в директивах #ifdef программ на языке C.

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

Переносимые программы

Перед каждым программистом, пишущим программу под какой-то из вариантов UNIX’а, в той или иной степени встает проблема сборки этой программы под другими вариантами UNIX’а. Так сложилось, что UNIX-совместимые операционные системы довольно сильно отличаются друг от друга, и приходится прикладывать некоторые усилия для обеспечения переносимости. Autoconf обеспечивает инфраструктуру, облегчающую эту задачу.

Теоретические вопросы переносимости

Согласно общему правилу не следует чрезмерно и без нужды увлекаться вопросами переносимости. С самого начала достаточно не писать кода, который, очевидно, будет работать только на машине, на которой он был скомпилирован: например, код, считающий, что младший байт в слове находится перед старшим, или же код с ассемблерными вставками, или же использование жестко привязанных к системе заголовочных файлов, например #include
(их, конечно же, можно использовать, обернув в соответствующие #ifdef). Если не допускать подобных ошибок, то работа по переносу значительно облегчится.

Теперь нужно проверить (и исправить, если нужно) сборку и работоспособность программы на «основных» вариантах UNIX: в данный момент это Linux и FreeBSD для свободно-распространяемых и Solaris – для коммерческих. Работу на остальных вариантах UNIX нужно исправлять только если:

• у вас есть к ним непосредственный доступ и немного свободного времени;
• ваши пользователи работают именно с этим UNIX’ом;
• кто-то, кто пользуется этим UNIX’ом, прислал вам исправления.

В процессе жизни программы она рано или поздно будет перенесена на все UNIX’ы, которые действительно имеют значение.

В документации на Autoconf есть целая глава «Существующие тесты» (Existing tests), в которой описано множество вариантов специфических заголовочных файлов, библиотек, функций, типов данных и прочего, которые можно проверить с помощью стандартных макросов Autoconf. Помимо этого, с помощью макроса AC_CHECK_HEADER() можно проверить существование заголовочного файла, с помощью AC_CHECK_LIB() можно проверить существование библиотеки, с помощью AC_CHECK_FUNC() – существование функции. Кроме того, там же можно прочитать о различных возможностях компилятора C, которые существуют не на всякой платформе, и о многом другом.

Практическая часть

Каждый исходный файл должен содержать в начале (до всех остальных директив #include) директиву препроцессора

Для создания этого файла нужно, во-первых, вписать в configure.in, ближе к началу, строчку

Во-вторых, запускаем программу autoheader, которая обработает configure.in и создаст файл config.h.in. Рекомендуется всегда использовать именно такое имя этого файла, и никакое другое, потому что так привычнее и понятнее. Если вы пользуетесь системой контроля версий, то добавьте в нее только файл config.h.in, и ни в коем случае не добавляйте файл config.h.

После того, как вы написали в своем скрипте configure.in все макросы, которые проверяют все возможности, используемые в программе, нужно обработать исходные файлы и «обернуть» все строки, в которых подключаются нестандартные заголовочные файлы, в директивы #ifdef/#endif, чтобы они подключались только на тех платформах, на которых их наличие было проверено скриптом configure и описано в файле config.h.

После внесения исправлений на предмет работы под очередным вариантом UNIX необходимо проверять, не сломалась ли компиляция под уже поддерживаемым вариантом.

Содержимое configure.in

Скрипт configure, который выполняется пользователем, представляет собой обычный скрипт на языке Bourne Shell. Этот скрипт генерируется из шаблона, configure.in, с помощью макропроцессора m4 (он похож на препроцессор языка C, но гораздо более мощный, и не завязан ни на один язык программирования). Вы, как разработчик пакета, редактируете, естественно, только шаблон, никогда не трогая сам файл configure. Скрипт configure генерируется из скрипта configure.in с помощью запуска программы autoconf.

Макросы

Внутри файла configure.in можно использовать специальные макросы, определенные пакетом Autoconf, вперемешку с обычным кодом на языке Bourne Shell. Ниже приведен пример минимального configure.in:

Названия макросов принято писать заглавными буквами. В данном примере используется четыре макроса: AC_INIT, AM_INIT_AUTOMAKE, AC_PROG_CC и AC_OUTPUT. Параметры макросов указаны в круглых скобках через запятую. Квадратные скобки фактически играют роль кавычек (m4 позволяет назначать кавычками любую последовательность символов).

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

Например, макрос AC_PROG_CC призван выяснить, какой компилятор C следует использовать. Если при вызове ./configure переменная окружения CC установлена в какое-то значение, то в качестве компилятора используется именно оно (например, можно задать компилятор с полным путем); в противном случае, проверяется, существует ли исполняемый файл ’gcc’, и может ли он скомпилировать тривиальную программу; если не может, то проверяет существование компилятора с именем ’cc’. Если все попытки закончились безуспешно, то пользователю сообщается об ошибке, и скрипт configure прекращает свою работу. Окончательно выясненное имя компилятора находится в переменной окружения CC.

Передача информации в Makefile

В качестве последнего шага скрипт configure вызывает специальный макрос AC_SUBST, передавая ему в качестве параметра имя этой переменной. Переменные, помеченные таким образом, называются ”выходными переменными” (output variables). В конце работы скрипт configure станет создавать файлы Makefile из соответствующих файлов Makefile.in. Предположим, что скрипт configure выяснил, что в качестве компилятора следует использовать программу ’gcc’ (то бишь, переменная окружения CC содержит значение ”gcc”), а внутри файла Makefile.in написано

В результате при создании файла Makefile выходная переменная CC (записанная в виде ”@CC@”) будет заменена на соответствующее значение переменной окружения

В файлах Makefile.in, которые Automake создает из Makefile.am, используется довольно много выходных переменных, в которых задаются имена множества программ, используемых для сборки вашего пакета. Вообще, выходные переменные – один из двух основных способов передачи информации о конфигурации в ваши файлы Makefile.

Обычно довольно редко потребуется использовать макрос AC_SUBST в скриптах configure.in: чаще всего он будет вызываться неявно, из других стандартных макросов. Например, макрос AC_CHECK_PROG превращает свой первый аргумент в выходную переменную.

Второй, более распространенный способ влияния на сборку программы – задание переменных препроцессора с помощью макроса AC_DEFINE. Например, если вы хотите выяснить, установлена ли в системе библиотека zlib, чтобы использовать её в своей программе, то можете сделать это с помощью макроса AC_CHECK_LIB, а в параметре action-if-found вызвать макрос AC_DEFINE с параметром HAVE_ZLIB. Потом в вашей программе можно будет пользоваться директивой препроцессора #ifdef HAVE_ZLIB, чтобы включить или выключить те или иные куски кода.

Все переменные препроцессора, объявленные с помощью макроса AC_DEFINE, помещаются в файл config.h (который генерируется из файла config.h.in на этапе конфигурации пакета).

Практическое применение Autoconf

В данном разделе мы рассмотрим применение Autoconf для подключения сторонних библиотек.

Предположим, вы хотите, чтобы если у пользователя в системе была установлена Zlib, то она использовалась бы для компрессии данных. Так как в нашей программе hello сложно придумать, что можно было бы компрессировать, то мы ограничимся тем, что будем выводить на экран дополнительное сообщение с версией этой библиотеки, пользуясь одной из её функций.

Zlib использует заголовочный файл zlib.h, библиотечный файл libz.a, а функция, возвращающая версию библиотеки, называется zlibVersion().

Чтобы на этапе конфигурации пакета определить наличие в системе заголовочного файла zlib.h, добавим в configure.in вызов макроса AC_CHECK_HEADERS(), а чтобы убедиться, что сами библиотечные файлы установлены, добавим макрос AC_CHECK_LIB().

Теперь наш файл configure.in выглядит так:

Запустим autoheader, чтобы обновить файл config.h.in, потом запустим autoconf, чтобы пересоздать скрипт configure. В файле config.h, который будет создан этим скриптом, объявлены два препроцессорных символа: HAVE_ZLIB_H, который определен, если присутствует файл zlib.h, и HAVE_LIBZ, который определен, если существует библиотека libz.

Воспользуемся функцией zlibVersion() в файле main.c, обернув её в директивы препроцессора:

Теперь можно запускать ./configure (скорее всего, на вашей машине стоят заголовочные файлы от Zlib и она сама. Если нет, то попробуйте без них, потом установите соответствующие пакеты и попробуйте еще раз):

И пересобираем нашу программу:

Библиотека libz автоматически оказалась добавлена в строку компиляции исполняемого файла, и его можно попробовать запустить:

Скрипт configure во время работы создает кэш результатов конфигурации, который сильно ускоряет результаты его работы. Этот кэш находится в файле config.cache. К сожалению, в этом кэше могут остаться устаревшие данные. Например, если вы сначала выполните наш скрипт configure без библиотеки Zlib, а потом установите её на машину и выполните его еще раз, то он не обнаружит этой библиотеки, потому что в кэше записано, что такой библиотеки нет. Просто удалите этот кэш-файл, и перезапустите configure.

Выводы

Активное использование Autoconf позволяет добиться большой гибкости при конфигурировании вашего программного пакета. После того, как вы стали использовать Automake вместо файлов Makefile, следующий шаг – дополнительные ключи конфигурации и поддержка переносимости программы между различными системами UNIX.

Источник