@anchor{Setup}
Скриптам, созданным Autoconf, нужна некоторая инициализационная информация, как то: где найти исходные тексты пакета; какие выходные файлы создавать. В нижеследующей главе описана инициализация и создание выходных файлов.
configure
@anchor{Input}
Каждый скрипт configure
должен первым делом вызвать макрос
AC_INIT
. Единственный обязательный макрос -- AC_OUTPUT
(see section Создание выходных файлов).
configure
проверяет существование этого
файла, чтобы убедиться, что это именно тот каталог с исходными текстами,
какой нужно. Иногда люди указывают неверный каталог с исходными текстами,
используя ключ командной строки `--srcdir'; эта проверка позволяет
не допускать таких инцидентов. Для детальной информации See section Запуск скриптов configure
.
Пакетам, которые выполняют ручную настройку или используют программу
install
, может понадобиться указать скрипту configure
,
где можно найти
другие скрипты командного процессора. Это выполняется с помощью вызова
макроса AC_CONFIG_AUX_DIR
, хотя используемые по умолчанию значения
в большинстве случаев будут правильными.
configure
, которые располагаются в каталоге dir.
Эти вспомогательные файлы используются при конфигурировании. Значение dir может
быть задано либо абсолютным путем, либо путем относительно `srcdir'.
Значением по умолчанию является первый из каталогов `srcdir', `srcdir/..'
или `srcdir/../..', в котором будет найден файл
`install-sh'. Проверка наличия других файлов не производится, так
что использование AC_PROG_INSTALL
не требует включения в
дистрибутив других вспомогательных файлов. Также проверяется наличие
файла `install.sh', но это имя является устаревшим, поскольку
некоторые программы make
имеют правило, которое создает файл
`install' из этого файла, в случае если `Makefile'
отсутствует.
@anchor{Output}
Каждый скрипт configure
, созданный Autoconf, должен заканчиваться
вызовом макроса AC_OUTPUT
. Этот макрос создает файлы `Makefile'
и, может быть, дополнительные файлы, которые являются результатом
конфигурации. Еще одним обязательным макросом является AC_INIT
(see section Нахождение ввода configure
).
Если вызывались макросы AC_CONFIG_HEADER
, AC_LINK_FILES
или
AC_CONFIG_SUBDIRS
, то этот макрос также создает файлы, указанные в
аргументах этих макросов.
Типичный вызов AC_OUTPUT
выглядит примерно так:
AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)
Вы можете переопределить имена входных файлов, добавив к file список
входных файлов, который разделен двоеточием. Например:
AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk)
AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)
Это позволит вам сохранить имена файлов в формате MS-DOS, или для добавления стандартных кусков кода кода в начало или конец файла.
В параметре extra-cmds можно указать команды, которые будут
вставлены в файл `config.status' и сработают после того, как было
сделано все остальное. В параметре init-cmds можно указать
команды, которые будут вставлены непосредственно перед extra-cmds,
причем configure
выполнит в них подстановку переменных, команды и
обратных слэшей. Аргумент init-cmds можно использовать для
передачи переменных из configure
в
extra-cmds. Если был вызван макрос AC_OUTPUT_COMMANDS
, то
команды,
переданные ему в качестве аргумента, выполняются прямо перед командами,
переданными макросу AC_OUTPUT
.
configure
. Этот макрос можно вызывать несколько
раз. Вот нереальный пример:
fubar=27
AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar)
AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])
Если вам нужно запустить make
в подкаталогах, то это следует
делать с помощью переменной MAKE
. Большинство версий программы
make
устанавливают значение переменной MAKE
равным имени
программы make
с дополнительно заданными ключами. (Но многие
версии не включаются сюда значения переменных, заданных в командной
строке, поэтому они не передаются автоматически). Некоторые старые версии команды
make
не устанавливают эту переменную. Следующий макрос позволяет
вам использовать переменную MAKE
даже таких старых версий.
make
определяет переменную MAKE
, то переменная
SET_MAKE
получает пустое значение. Иначе, определяется переменная
SET_MAKE
со значением `MAKE=make'. Для переменной SET_MAKE
вызывается макрос AC_SUBST
.
Для использования данного макроса поместите следующую строку в каждый из
файлов `Makefile.in', в котором производится запуск MAKE
для подкаталогов:
@SET_MAKE@
@anchor{Makefile Substitutions}
Каждый подкаталог дистрибутива, который содержит что либо, что должно
компилироваться или устанавливаться, должен поставляться с файлом
`Makefile.in', из которого configure
создаст файл
`Makefile' для данного каталога. Для создания `Makefile',
configure
выполнит простую подстановку переменных, заменяя
вхождения `@variable@' в файле `Makefile.in' на
значения, которые определены configure
для данной
переменной. Переменные, которые подставляются в выходных файлах таким
способом, называются выходными переменными (output variables). Они
являются обычными переменными командного процессора, которые
устанавливаются в configure
. Для того, чтобы configure
подставлял в выходных файлах определенную переменную, необходимо вызвать
макрос AC_SUBST
с именем переменной в качестве аргумента. Любое
вхождение `@variable@' для других переменных остается
неизмененным. Для получения дополнительной информации о создании
выходных переменных с помощью макроса AC_SUBST
See section Установка выходных переменных.
Пакеты программного обеспечения, использующие скрипт configure
, должны
распространяться с файлами `Makefile.in', но не с файлами `Makefile';
таким образом, пользователь должен перед компиляцией сконфигурировать
программный пакет так, чтобы он соответствовал используемой системе.
See section `Makefile Conventions' in The GNU Coding Standards, для получения информации о том, что можно помещать в файлы `Makefile'.
@anchor{Preset Output Variables}
Некоторые выходные переменные заранее устанавливаются макросами Autoconf. Некоторые макросы Autoconf устанавливают дополнительные выходные переменные, которые упомянуты в описаниях этих макросов. Полный список выходных переменных находится в section Индекс выходных переменных. See section `Variables for Installation Directories' in The GNU Coding Standards, для дополнительной информации о переменных с именами, которые заканчиваются на `dir'.
configure
и выдает имя входного файла. AC_OUTPUT
добавляет
строку комментария, содержащую эту переменную, в начало каждого
создаваемого файла `Makefile'. Для других файлов вы должны
сослаться на эту переменную в комментарии в заголовке каждого входного
файла. Например, входной скрипт командного процессора должен начинаться
примерно так:
#! /bin/sh
# @configure_input@
Наличие этой строки также напоминает людям, редактирующим этот файл, что
перед использованием его необходимо обработать с помощью configure
.
srcdir
.
configure
, то
значение по умолчанию устанавливается при вызове макроса
AC_PROG_CC
(или равно пустому значению, если вы не вызываете этот
макрос). configure
использует эту переменную при компиляции
программ для тестирования возможностей компилятора C.
configure
, то значение по
умолчанию равно пустому значению. configure
использует эту
переменную при компиляции программ или обработке препроцессором для
тестирования возможностей компилятора C.
configure
, то
значение по умолчанию устанавливается при вызове макроса
AC_PROG_CXX
(или равно пустому значению, если вы не вызываете этот
макрос). configure
использует эту переменную при компиляции
программ для тестирования возможностей компилятора C++.
configure
, то
значение по умолчанию устанавливается при вызове макроса
AC_PROG_F77
(или равно пустому значению, если вы не вызываете этот
макрос). configure
использует эту переменную при компиляции
программ для тестирования возможностей компилятора Fortran 77.
AC_CONFIG_HEADER
, то configure
заменяет вхождения
`@DEFS@' на `-DHAVE_CONFIG_H' (see section Заголовочные файлы конфигурации). Эта переменная не определена во время выполнения тестов
configure
, она определяется только при создании выходных
файлов. See section Установка выходных переменных, для описания того, как получить
результаты предыдущих тестов.
configure
, то по умолчанию имеет пустое
значение. configure
использует эту переменную при компоновке
программ для тестирования возможностей С.
@anchor{Build Directories}
Вы можете поддерживать одновременную компиляцию пакета программного обеспечения для различных архитектур из одной и той же копии исходного кода. Объектные файлы для каждой из архитектур хранятся в отдельных каталогах.
Для поддержки этого make
использует переменную VPATH
для
поиска файлов, которые находятся в каталоге с исходными текстами. Такая
возможность
поддерживается GNU make
и большинством других программ
make
свежих версий. Старые версии программы make
не
поддерживают переменную VPATH
; при их использовании
исходные тексты должны находиться в том же каталоге, что и объектные
файлы.
Для поддержки VPATH
каждый файл `Makefile.in' должен
содержать две строки, которые могут выглядеть следующим образом:
srcdir = @srcdir@
VPATH = @srcdir@
Не надо устанавливать VPATH
в значение другой переменной,
например `VPATH = $(srcdir)', поскольку некоторые версии
make
не выполняют подстановку переменных для
VPATH
.
configure
подставляет правильное значение srcdir
при
создании файла `Makefile'.
Не используйте переменную $<
программы make
, которая
разворачивается в имя файла с полным путем (найденным с помощью
VPATH
), причем только в явных правилах. (Неявные правила,
например, `.c.o', сообщают, как создать файл `.o' из файла
`.c'.) Некоторые версии make
не устанавливают $<
в
явных правилах; они подставляют вместо него пустое значение.
Вместо этого командные строки`Makefile' всегда должны ссылаться на
файлы с исходными текстами, с добавлением к ним префикса
`$(srcdir)/'. Например:
time.info: time.texinfo
$(MAKEINFO) $(srcdir)/time.texinfo
@anchor{Automatic Remaking}
Вы можете поместить правила, упомянутые ниже, в файл `Makefile.in' верхнего уровня пакета, для того чтобы автоматически обновлять информацию о конфигурации при изменении файлов конфигурации. Этот пример использует все дополнительные файлы, такие как `aclocal.m4', а также то, что относятся к заголовочным файлам конфигурации. Уберите из правила для `Makefile.in' файлы, не использующиеся в вашем пакете.
Префикс `${srcdir}/' добавлен из-за ограничений механизма
использования VPATH
.
Файлы `stamp-' являются необходимыми, поскольку время последнего
изменения файлов `config.h.in' и `config.h' останется прежним,
если пересоздание этих файлов не изменит их содержимого. Эта возможность
позволяет избежать ненужной перекомпиляции. Вы должны включить
файл `stamp-h.in' в дистрибутив вашего пакета, так что make
будет считать `config.h.in' обновленным. На некоторых старых
системах BSD, команда touch
или любая другая, создающая файл
нулевой длины, не обновляет время изменения этого файла, так что
используйте для правильной работы команду echo
.
${srcdir}/configure: configure.in aclocal.m4
cd ${srcdir} && autoconf
# autoheader мог не изменить config.h.in, так что обновить дату stamp-файла.
${srcdir}/config.h.in: stamp-h.in
${srcdir}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
config.h.top config.h.bot
cd ${srcdir} && autoheader
echo timestamp > ${srcdir}/stamp-h.in
config.h: stamp-h
stamp-h: config.h.in config.status
./config.status
Makefile: Makefile.in config.status
./config.status
config.status: configure
./config.status --recheck
Вдобавок вы должны передать `echo timestamp > stamp-h' в аргументе
extra-cmds макросу AC_OUTPUT
, так что
`config.status' будет гарантировать, что файл `config.h' будет
рассматриваться как обновленный. See section Создание выходных файлов, для дополнительной
информации о AC_OUTPUT
.
See section Воссоздание конфигурации, где описаны дополнительные примеры обработки конфигурационных зависимостей.
@anchor{Configuration Headers}
Когда пакет производит тестирование большого количества символов
препроцессора C, то командная строка ключей `-D', передаваемых
компилятору, может получиться достаточно длинной. Это вызывает две
проблемы. Первая заключается в том, что вывод результатов команды
make
будет тяжело читать в поисках ошибок. Вторая и более
серьезная заключается в том, что длина командной строки может
превысить предельную длину командной строки в некоторых операционных
системах. В качестве альтернативы передаче компилятору ключей `-D',
скрипты configure
могут создавать заголовочные файлы C, которые
содержат директивы `#define'. Макрос AC_CONFIG_HEADER
выбирает этот способ выдачи результатов. Макрос должен быть вызван сразу
после вызова AC_INIT
.
Пакет должен подключить с помощью #include
заголовочный файл
настройки до подключения остальных заголовочных файлов, чтобы избежать
несовместимости в объявлениях (например, если этот файл переопределяет
const
). Используйте директиву `#include <config.h>' вместо
`#include "config.h"', и передайте компилятору C
ключ `-I.' (или `-I..', смотря где находится
файл `config.h'). Таким образом, даже если сам каталог с исходными
текстами сконфигурирован (например, для создания дистрибутива), то
другие сборочные каталоги можно будет сконфигурировать, не используя при
этом файл `config.h' и каталога с исходными текстами.
AC_OUTPUT
создать файлы с именами из
разделенного пробелами списка header-to-create, которые будут
содержать директивы #define
препроцессора C, и заменить
`@DEFS@' в созданных файлах на `-DHAVE_CONFIG_H' вместо
значения DEFS
. Обычным значением для header-to-create
является `config.h'.
Если header-to-create уже существует и его содержимое не отличается от того, что в него хотят поместить, то он остается неизмененным. Это позволяет вносить некоторые изменения в конфигурацию без ненужной перекомпиляции объектных файлов, которые зависят от данных заголовочных файлов.
Обычно входной файл называется `header-to-create.in'; однако
вы можете переопределить имя входного файла, добавив к
header-to-create список входных файлов, разделенный двоеточием.
Примеры:
AC_CONFIG_HEADER(defines.h:defines.hin)
AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)
Это позволяет вам сохранить имена в виде, приемлемом для использования в MS-DOS, а также для добавления стандартных кусков кода к файлам.
@anchor{Header Templates}
Ваш дистрибутив должен содержать файл шаблона, который должен выглядеть
так, как будет выглядеть окончательный заголовочный файл, включая
комментарии, но при этом все значения директив #define
в нем
будут установлены по умолчанию. Например,
предположим, что ваш файл `configure.in' производит следующие
вызовы:
AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)
Для этого примера необходимо вставить в `conf.h.in' нижеследующий
код. В системах, в которых есть `unistd.h',
configure
заменит 0 на 1. В других системах эта строка останется
неизмененной.
/* Определить со значением 1 если у вас есть unistd.h. */
#define HAVE_UNISTD_H 0
Если ваш код проверяет конфигурацию, используя директиву
препроцессора #ifdef
вместо #if
, то значение по умолчанию
может быть удалено директивой #undef
вместо определения
значения. В системах в которых имеется файл `unistd.h',
configure
изменит вторую строку на `#define HAVE_UNISTD_H
1'. В других системах эта строка будет закомментирована (в случае, если
система предопределяет этот символ).
/* Определяется, если в системе есть unistd.h. */
#undef HAVE_UNISTD_H
autoheader
для создания `config.h.in'@anchor{Invoking autoheader}
Программа autoheader
может создать шаблон файла, содержащего
директивы `#define', для использования с configure
. Если
`configure.in' использует AC_CONFIG_HEADER(file)
, то
autoheader
создает `file.in'; если в качестве
аргумента задано несколько имен файлов, то используется только первое
имя. В противном случае autoheader
создаст файл `config.h.in'.
Если вы зададите аргумент программе autoheader
, то она будет
считывать данные из этого файла, а не из файла `configure.in' и
будет выводить данные в поток стандартного вывода вместо
`config.h.in'. Если вы зададите autoheader
аргумент
`-', то программа будет считывать данные со стандартного ввода
вместо `configure.in' и выдавать результаты на стандартный вывод.
autoheader
сканирует файл `configure.in' и
определяет, какие символы препроцессора C могут быть определены в нем.
Программа копирует комментарии и директивы #define
и #undef
из файла с именем `acconfig.h', который поставляется вместе с Autoconf.
Программа также использует файл с именем `acconfig.h' из текущего
каталога, если он присутствует. Если вы определите с помощью макроса
AC_DEFINE
дополнительные символы, то вы должны создать этот файл с
записями для них. Для символов, определенных макросами
AC_CHECK_HEADERS
, AC_CHECK_FUNCS
, AC_CHECK_SIZEOF
или AC_CHECK_LIB
, программа autoheader
сама создает комментарии
и директивы #undef
, а не копирует их из файла, поскольку
количество возможных символов фактически бесконечно.
Файл, который создается autoheader
, содержит в основном директивы
#define
и #undef
и комментарии к ним. Если
`./acconfig.h' содержит строку `@TOP@', то autoheader
копирует строки, которые находятся выше строки `@TOP@', прямо в
заголовок создаваемого файла. Аналогично, если `./acconfig.h' содержит
строку `@BOTTOM@', то autoheader
скопирует строки, расположенные
сразу после этой строки, в конец создаваемого файла. Можно не
использовать как `@TOP@', так и `@BOTTOM@'.
Другой способ добиться точно такого же результата -- создать
в текущем каталоге файлы `file.top' (обычно
`config.h.top') и/или `file.bot'. Если эти файлы
существуют, то autoheader
копирует их содержимое в начало и в конец
выводимых данных. Их использование не рекомендуется, поскольку имена этих
файлов содержат две точки и не могут применяться в MS-DOS; также это
увеличивает содержимое каталога еще на два файла. Но если вы воспользуетесь
ключом `--localdir=dir' для использования `acconfig.h'
находящегося в другом каталоге, то эти файлы позволят вам вставлять
произвольные куски кода в каждый конкретный файл `config.h.in'.
autoheader
распознает следующие ключи командной строки:
--help
-h
--localdir=dir
-l dir
--macrodir=dir
-m dir
AC_MACRODIR
, указывающую на этот каталог; этот ключ переопределяет
значение переменной среды.
--version
@anchor{Subdirectories}
В большинстве ситуаций для создания
файлов `Makefile' в подкаталогах достаточно вызова макроса
AC_OUTPUT
. Однако скрипты configure
, которые
контролируют более чем один независимый пакет, могут использовать макрос
AC_CONFIG_SUBDIRS
для запуска скриптов configure
для других
пакетов, находящихся в подкаталогах.
AC_OUTPUT
запустить configure
в каждом
подкаталоге dir, которые заданы в списке через пробел.
Если заданный
каталог dir не найден, то сообщение об ошибке не выдается, поэтому
скрипт configure
может производить конфигурацию, даже если часть
подкаталогов отсутствует. Если заданный каталог dir содержит файл
`configure.in', но не содержит configure
, то будет
использоваться Cygnus-версия скрипта configure
, местонахождение которой
определяется макросом AC_CONFIG_AUXDIR
.
Скриптам configure
, находящимся в подкаталогах, передается та же
командная строка, что задана текущему скрипту configure
, только с
некоторыми изменениями, когда это необходимо (например, исправление
относительных путевых имен для кэш-файла или каталога с исходными
текстами). Этот макрос также устанавливает выходную переменную
subdirs
равной списку каталогов `dir ...'. Правила
`Makefile' могут использовать эту переменную для определения того,
в какие подкаталоги будет осуществляться рекурсивный переход. Этот
макрос может вызываться много раз.
@anchor{Default Prefix}
По умолчанию configure
задает префикс для устанавливаемых файлов
равным `/usr/local'. Пользователь configure
может выбрать
другой префикс, используя ключи командной строки `--prefix' и
`--exec-prefix'. Есть два способа изменения значения по
умолчанию: при создании configure
и при его запуске.
Некоторые пакеты программного обеспечения могут требовать установки по
умолчанию в каталог, отличный от `/usr/local'. Чтобы изменить
значение по умолчанию, используйте макрос AC_PREFIX_DEFAULT
.
Для пользователей может быть удобным, чтобы configure
попытался
угадать префикс для установки на основе расположения некоторых программ,
которые уже установлены в системе. Если вы хотите именно этого,
используйте макрос AC_PREFIX_PROGRAM
.
PATH
. Если
program найдена, то установить префикс равным родительскому
каталогу каталога, в котором находится program; иначе оставить
неизмененным значение префикса, указанного `Makefile.in'. Например,
если значением program является gcc
, а в путях найдена программа
`/usr/local/gnu/bin/gcc', то значением префикса будет
`/usr/local/gnu'.
configure
@anchor{Versions}
Следующие макросы используются для работы с номерами версий в скриптах
configure
. Их использование не обязательно.
configure
, является более старой, чем version, то в
стандартный поток сообщений об ошибках выдается сообщение и
configure
не создается. Например:
AC_PREREQ(1.8)
Этот макрос полезен в том случае, если ваш `configure.in'
полагается на неочевидное поведение, которое изменилось между
версиями Autoconf. Если вам необходимы только недавно добавленные
макросы, то AC_PREREQ
чуть менее полезен, поскольку программа
autoconf
и так сообщит пользователю о том, какие макросы не
найдены. То же самое случится в том случае, если файл `configure.in'
будет обрабатываться версией Autoconf, более старой, чем та, в которой
был добавлен макрос AC_PREREQ
.
configure
,
удаляя знаки доллара и двойные кавычки. Этот макрос позволяет
вам помещать метки версий из файла `configure.in' в
configure
, но при этом RCS или CVS не станут изменять
их при помещении configure
в репозиторий. Таким образом, вы
можете легко определить, какая версия
`configure.in' соответствует конкретному configure
.
Хорошей идеей является вызов этого макроса перед AC_INIT
, чтобы
номер ревизии располагался в начале и `configure.in', и
configure
. Для поддержки этого выдача AC_REVISION
начинается с `#! /bin/sh', подобно обычному началу скрипта
configure
.
Вот пример этой строки в `configure.in':
AC_REVISION($Revision: 1.1.1.1 $)dnl
это создает в configure
строки:
#! /bin/sh
# From configure.in Revision: 1.30
Go to the first, previous, next, last section, table of contents.