@anchor{Results}
После того, как скрипт configure выяснил существование какой-либо
возможности, что можно сделать, чтобы записать эту информацию? Есть
четыре варианта: определить символ препроцессора С, установить
переменную в выходном файле, сохранить результат в кэш-файле для
использования при последующих запусках configure и выдать
сообщение, позволяющее пользователю узнать результат теста.
@anchor{Defining Symbols}
Обычно после проверки какой-либо возможности устанавливается символ
препроцессора, отражающий результат проверки. Это происходит при вызове
макроса AC_DEFINE или
AC_DEFINE_UNQUOTED.
По умолчанию макрос AC_OUTPUT помещает символы, определенные
этими макросами в выходную переменную DEFS, которая по одному
ключу `-Dsymbol=value' на каждый символ. В отличии от
Autoconf версии 1, переменная DEFS не
определена в течении работы configure. Для проверки того,
определен ли уже какой-либо символ препроцессора C,
проверьте значение соответствующей переменной кэша, как показано в этом
примере:
AC_CHECK_FUNC(vprintf, AC_DEFINE(HAVE_VPRINTF))
if test "$ac_cv_func_vprintf" != yes; then
AC_CHECK_FUNC(_doprnt, AC_DEFINE(HAVE_DOPRNT))
fi
Если был вызван макрос AC_CONFIG_HEADER, то AC_OUTPUT
вместо определения переменной DEFS создает заголовочный файл
путем подстановки правильных значений в директивы #define,
заданные в файле-шаблоне. See section Заголовочные файлы конфигурации, для
дополнительной информации об этом способе вывода результатов.
AC_CONFIG_HEADER, то он не должен содержать символы
`#', поскольку make имеет склонен проглатывать их. Для
использования переменной командного процессора (которая необходима, если
нужно определить значение, содержащее символ, являющийся кавычкой в
m4 `[' или `]') вам следует использовать
AC_DEFINE_UNQUOTED. Аргумент description полезен только в
том случае, если вы используете макрос AC_CONFIG_HEADER. В этом
случае description будет помещен в созданный файл
`config.h.in' в качества комментария к определению символа; макросу не нужно быть
упомянутым в `acconfig.h'. Следующий пример определяет переменную
препроцессора C EQUATION со значением, равным строковой константе
`"$a > $b"':
AC_DEFINE(EQUATION, "$a > $b")
AC_DEFINE, но над переменными variable и
value выполняется ряд преобразований: подстановка переменных
(`$'), подстановка результатов
выполнения команд (``') и экранирование символов обратной косой черты
(`\'). Символы одиночных и двойных кавычек в value не имеют
специального смысла. Используйте этот макрос вместо AC_DEFINE,
когда variable или value являются переменными командного
процессора. Примеры:
AC_DEFINE_UNQUOTED(config_machfile, "${machfile}")
AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
AC_DEFINE_UNQUOTED(${ac_tr_hdr})
Из-за синтаксических странностей командного процессора Bourne не следует
использовать точку с запятой для разделения вызовов макросов
AC_DEFINE или AC_DEFINE_UNQUOTED от вызова других макросов
или кода командного процессора; это может привести к синтаксическим ошибкам
в результирующем скрипте configure. Вместо этого
используйте пробелы или переводы строк. То есть, следует писать так:
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")
либо так:
AC_CHECK_HEADER(elf.h,
AC_DEFINE(SVR4)
LIBS="$LIBS -lelf")
но не так:
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")
@anchor{Setting Output Variables}
Одним из способов записи результатов тестов является установка
выходных переменных, то есть переменных командного
процессора, чьи значения подставляются в файлы, выводимые
configure. Нижеприведенные макросы используются для создания
новых выходных переменных. See section Установка выходных переменных, где
приведен список всегда присутствующих выходных переменных.
AC_OUTPUT подставлять переменную variable в
выходные файлы (обычно это один или несколько файлов `Makefile').
Это означает, что AC_OUTPUT будет заменять вхождения
`@variable@' во входных файлах на значение переменной
командного процессора variable, которое она имела при вызове макроса
AC_OUTPUT. Значение variable не должно содержать символы
новой строки.
AC_OUTPUT вставить (без подстановок) в
выходные файлы содержимое файла, указанного в переменной командного
процессора variable. Это означает, что AC_OUTPUT будет
заменять вхождения `@variable@' в выходных файлах (таких
как `Makefile.in') на содержимое файла, имя которого содержалось в
переменной variable в момент вызова макроса
AC_OUTPUT. Установите значение этой переменной в `/dev/null' для
случаев, когда вставляемый файл отсутствует.
Этот макрос полезен для вставки фрагментов `Makefile', содержащих
специальные зависимости или другие директивы make для отдельных
типов машин и целей в результирующие файлы `Makefile'. Например,
файл `configure.in' может содержать:
AC_SUBST_FILE(host_frag)dnl
host_frag=$srcdir/conf/sun4.mh
и файл `Makefile.in' может содержать:
@host_frag@
@anchor{Caching Results}
Чтобы избежать повторяющихся проверок одних и тех же возможностей в
различных скриптах configure (или при повторных вызовах
одного скрипта), configure сохраняет результаты многих
проверок в кэш-файле. Если при запуске скрипта configure
тот находит кэш-файл, то считывает результаты, полученные при
предыдущих запусках, и не выполняет проверки, результат которых уже
получен. Благодаря этому configure может работать намного
быстрее, чем если бы при каждом запуске приходилось заново выполнять все
проверки.
configure не был задан ключ `--quiet' или `--silent',
то выдать сообщение о том, что результаты были взяты из кэша; в
противном случае запустить код командного процессора
commands-to-set-it. Эти команды не должны иметь побочных
эффектов, за исключением установки переменной cache-id. В
частности, они не должны вызывать макрос AC_DEFINE; это должен
делать код, следующий за вызовом AC_CACHE_VAL, основываясь на
кэшированном значении. Они также не должны выдавать никаких сообщений,
например, с помощью макроса AC_MSG_CHECKING; это надо выполнять
до вызова AC_CACHE_VAL, так что сообщения будут печататься вне
зависимости от того, будут ли результаты взяты из кэша или будут
определены с помощью выполнения кода командного процессора. Если для
определения значения будет запущен код командного процессора, то
полученное значение будет сохранено в кэш-файле перед тем, как
configure будет создавать выходные файлы. See section Имена переменных кэша, для того чтобы узнать, как выбрать имя переменной
cache-id.
AC_CACHE_VAL, которая берет на себя заботу о выдаче
сообщений. Этот макрос обеспечивает удобную и короткую форму записи
наиболее распространенных способов
использования этих макросов. Он вызывает макрос AC_MSG_CHECKING
для выдачи сообщения message, затем вызывает AC_CACHE_VAL с
аргументами cache-id и commands и, наконец, вызывает
AC_MSG_RESULT с аргументом cache-id.
AC_INIT.
AC_OUTPUT, но полезно бывает вызывать
AC_CACHE_SAVE в ключевых точке файла `configure.in'. При
это кэш сохраняется на тот случай, если работа скрипта `configure'
будет прервана.
@anchor{Cache Variable Names}
Имена переменных кэша должны иметь следующий формат:
package-prefix_cv_value-type_specific-value[_additional-options]
Например, `ac_cv_header_stat_broken' или `ac_cv_prog_gcc_traditional'. Имя переменной состоит из следующих частей:
_cv_
Значения кэшированных переменных не могут содержать переводы строк. Обычно их значения являются логическими значениями (`yes' или `no') или именами файлов или функций, поэтому это ограничение не критично.
@anchor{Cache Files}
Кэш-файл --- это скрипт командного процессора, который хранит результаты тестов конфигурации, проведенных на одной системе, так что они могут совместно использоваться разными скриптами настройки, или при нескольких запусках одного и того же скрипта configure. На других системах этот файл использовать бесполезно. Если содержимое этого файла по некоторым причинам является неверным, то пользователь может удалить или отредактировать его.
По умолчанию в качестве кэш-файла `configure' использует файл
`./config.cache', создавая его, если он не существует.
configure распознает ключ командной строки
`--cache-file=file', который позволяет использовать другой
кэш-файл; этот ключ используется configure, когда он вызывает
скрипты configure, находящиеся в подкаталогах, так что они
используют общий кэш. See section Настройка других пакетов, находящихся в подкаталогах, где описано, как задавать
подкаталоги с помощью макроса AC_CONFIG_SUBDIRS.
Использование ключа `--cache-file=/dev/null' запрещает кэширование,
например, для отладки configure. Скрипт `config.status'
смотрит на кэш-файл только если запустить его с ключом `--recheck',
чтобы повторно выполнить configure. Если вы
предчувствуете долгий период отладки, то можете запретить загрузку и
сохранение кэша путем переопределения макросов работы с кэшем в начале
`configure.in':
define([AC_CACHE_LOAD], )dnl
define([AC_CACHE_SAVE], )dnl
AC_INIT(whatever)
... rest of configure.in ...
Попытка распространения кэш-файлов для определенных типов систем неверна в корне. Пытаясь сделать это, вы получаете полную свободу совершать ошибки, а также сталкиваетесь с массой административных проблем, связанных с поддержкой этих файлов. Для возможностей, которые нельзя определить автоматически, используйте стандартный способ канонического типа системы и компоновки файлов (see section Ручная настройка).
На отдельной системе кэш-файл постепенно будет накапливать результаты
запусков скрипта configure; первоначально он вообще не будет
существовать. Запуск configure объединяет новые кэшированные
результаты с уже существующим кэш-файлом. Для того, чтобы сделать работу
скрипта более простой, скрипт инициализации на данной машине, может
указать общесистемный кэш-файл, который будет использоваться вместо
используемого по умолчанию, поскольку каждый раз используется один и
тот же компилятор С (see section Установка значений по умолчанию для машины).
Если ваш скрипт, или макрос, вызываемые из `configure.in',
прерывает процесс настройки, то полезно будет сохранить
кэшированные данные несколько раз в ключевых точках скрипта. Делая это,
вы уменьшите время, затраченное при перезапуске скрипта конфигурации
после исправления ошибки, которая вызвала предыдущий останов
работы.
... AC_INIT, etc. ...
dnl проверки программ
AC_PROG_CC
AC_PROG_GCC_TRADITIONAL
... дополнительные проверки программ...
AC_CACHE_SAVE
dnl проверка библиотек
AC_CHECK_LIB(nsl, gethostbyname)
AC_CHECK_LIB(socket, connect)
... другие проверки библиотек ...
AC_CACHE_SAVE
dnl Might abort...
AM_PATH_GTK(1.0.2, , exit 1)
AM_PATH_GTKMM(0.9.5, , exit 1)
@anchor{Printing Messages}
Скрипты configure должны сообщать пользователям различную
информацию. Следующие макросы различными способами выдают
сообщения. Аргументы для каждого из макросов помещаются в двойные
кавычки, используемые командным процессором, так что в этих аргументах
будет выполняться подстановка переменных и специальных символов. Вы можете
напечатать сообщение, содержащее запятую, поместив сообщение в кавычки,
используемые программой m4:
AC_MSG_RESULT([never mind, I found the BASIC compiler])
Все эти макросы являются надстройками над командой
echo. Скрипты configure должны крайне редко использовать
команду
echo для выдачи сообщения пользователю. Использование этих
макросов позволяет легко изменить способ, каким выдается каждый из типов
сообщений; такие изменения можно будет внести в определение макроса, и
все вызовы этого макроса изменят свой вид автоматически.
configure проверяет конкретную
возможность. Этот макрос печатает сообщение, которое начинается с
`checking ' и заканчивается `...' без перехода на новую
строку. Вслед за вызовом этого макроса следует использовать макрос
AC_MSG_RESULT, который выдает результат проверки и символ перевода
строки. Аргумент feature-description должен содержать что-нибудь
типа `понимает ли компилятор Fortran комментарии в стиле C++'
или `for c89'.
Этот макрос ничего не выводит, если configure запущен с ключами
`--quiet' или `--silent'.
AC_MSG_CHECKING
и аргумент result-description по смыслу должен дополнять сообщение
выданное вызовом AC_MSG_CHECKING.
Этот макрос ничего не выводит, сели configure запущен с ключами
`--quiet' или `--silent'.
configure. Этот макрос печатает сообщение об ошибке в стандартный
поток вывода и заканчивает работу configure с ненулевым статусом.
Аргумент error-description должен содержать что-то подобное
`неправильное значение $HOME для \$HOME'.
configure о возможной проблеме. Этот
макрос выдает сообщение в стандартный поток сообщений об ошибках; после
этого configure продолжает свое выполнение, так что макросы,
вызвавший AC_MSG_WARN должен предоставить действия по умолчанию
для ситуаций, о которых он выдавал предупреждения. Аргумент
problem-description должен содержать что-то подобное `кажется
ln -s создает жесткие ссылки'.
Следующие два макроса являются устаревшими и являются альтернативой для
макросов AC_MSG_CHECKING и AC_MSG_RESULT.
AC_MSG_CHECKING, за исключением того, что он
выдает символ перевода строки после вывода feature-description.
Он в основном полезен для выдачи общего описания группы проверок,
например:
AC_CHECKING(if stack overflow is detectable)
AC_MSG_RESULT, за исключением того, что его
вызов следует за вызовом AC_CHECKING, а не
AC_MSG_CHECKING; выдаваемое им сообщение начинается с символа
табуляции. Этот макрос считается устаревшим.
Go to the first, previous, next, last section, table of contents.