6. Результаты тестов

После того, как скрипт configure выяснил существование какой-либо возможности, что можно сделать, чтобы записать эту информацию? Есть четыре варианта: определить символ препроцессора С, установить переменную в выходном файле, сохранить результат в кэш-файле для использования при последующих запусках configure и выдать сообщение, позволяющее пользователю узнать результат теста.

6.1 Определение символов препроцессора С
6.2 Установка выходных переменных
6.3 Кэширование результатов		Ускорение работы при последующих запусках configure.
6.4 Выдача сообщений

6.1 Определение символов препроцессора С

Обычно после проверки какой-либо возможности устанавливается символ препроцессора, отражающий результат проверки. Это происходит при вызове макроса 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 3.4 Заголовочные файлы конфигурации, для дополнительной информации об этом способе вывода результатов.

Macro: AC_DEFINE (variable [, value [, description]])

Определяет переменную препроцессора C variable. Если аргумент value задан, то устанавливает переменную variable в это значение (без изменений), в противном случае устанавливает ее равной 1. value не должен содержать символов перевода строки, а если вы не используете 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")

Macro: AC_DEFINE_UNQUOTED (variable [, value [, description]])

Подобно 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")

6.2 Установка выходных переменных

Одним из способов записи результатов тестов является установка выходных переменных, то есть переменных командного процессора, чьи значения подставляются в файлы, выводимые configure. Приведенные ниже макросы используются для создания новых выходных переменных. See section 6.2 Установка выходных переменных, где приведен список всегда присутствующих выходных переменных.

Macro: AC_SUBST (variable)

Создает выходную переменную из переменной командного процессора. Заставляет AC_OUTPUT подставлять переменную variable в выходные файлы (обычно это один или несколько файлов `Makefile'). Это означает, что AC_OUTPUT будет заменять вхождения `@variable@' во входных файлах на значение переменной командного процессора variable, которое она имела при вызове макроса AC_OUTPUT. Значение variable не должно содержать символы новой строки.

Macro: AC_SUBST_FILE (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@

6.3 Кэширование результатов

Чтобы избежать повторяющихся проверок одних и тех же возможностей в различных скриптах configure (или при повторных вызовах одного скрипта), configure сохраняет результаты многих проверок в кэш-файле. Если при запуске скрипта configure тот находит кэш-файл, то считывает результаты, полученные при предыдущих запусках, и не выполняет проверки, результат которых уже получен. Благодаря этому configure может работать намного быстрее, чем если бы при каждом запуске приходилось заново выполнять все проверки.

Macro: AC_CACHE_VAL (cache-id, commands-to-set-it)

Проверяет, доступны ли результаты проверки, на которые указывает cache-id. Если результаты проверки находятся в кэше, и скрипту configure не был задан ключ `--quiet' или `--silent', то выдать сообщение о том, что результаты были взяты из кэша; в противном случае запустить код командного процессора commands-to-set-it. Эти команды не должны иметь побочных эффектов, за исключением установки переменной cache-id. В частности, они не должны вызывать макрос AC_DEFINE; это должен делать код, следующий за вызовом AC_CACHE_VAL, основываясь на кэшированном значении. Они также не должны выдавать никаких сообщений, например, с помощью макроса AC_MSG_CHECKING; это надо выполнять до вызова AC_CACHE_VAL, так что сообщения будут печататься вне зависимости от того, будут ли результаты взяты из кэша или будут определены с помощью выполнения кода командного процессора. Если для определения значения будет запущен код командного процессора, то полученное значение будет сохранено в кэш-файле перед тем, как configure будет создавать выходные файлы. See section 6.3.1 Имена переменных кэша, чтобы узнать, как выбрать имя переменной cache-id.

Macro: AC_CACHE_CHECK (message, cache-id, commands)

Обертка для макроса AC_CACHE_VAL, которая берет на себя заботу о выдаче сообщений. Этот макрос обеспечивает удобную и короткую форму записи наиболее распространенных способов использования этих макросов. Он вызывает макрос AC_MSG_CHECKING для выдачи сообщения message, затем вызывает AC_CACHE_VAL с аргументами cache-id и commands и, наконец, AC_MSG_RESULT с аргументом cache-id.

Macro: AC_CACHE_LOAD

Загружает значения из существующего кэш-файла или создает новый, если кэш-файл не найден. Автоматически вызывается из макроса AC_INIT.

Macro: AC_CACHE_SAVE

Записывает все кэшированные значения в кэш-файл. Этот макрос автоматически из макроса AC_OUTPUT, но полезно бывает вызывать AC_CACHE_SAVE в ключевых точке файла `configure.in'. При это кэш сохраняется на тот случай, если работа скрипта `configure' будет прервана.

6.3.1 Имена переменных кэша
6.3.2 Кэш-файлы		Файлы, которые configure использует для кэширования.

6.3.1 Имена переменных кэша

Имена переменных кэша должны иметь следующий формат:

package-prefix_cv_value-type_specific-value[_additional-options]

Например, `ac_cv_header_stat_broken' или `ac_cv_prog_gcc_traditional'. Имя переменной состоит из следующих частей:

package-prefix

Сокращенное название вашего пакета или организации; с такого же префикса вы должны начинать локальные макросы Autoconf, но только здесь этот префикс записывается в нижнем регистре. Макросы, распространяемые с Autoconf, используют префикс `ac'.

_cv_

Показывает, что эта переменная командного процессора является кэшированным значением.

value-type

Соглашение по классификации значений кэша для создания рациональной системы наименования. Значения, используемые в Autoconf, перечислены в 7.2 Имена макросов.

specific-value

Для какого члена класса кэшированных значений применяется данный тест. Например, к какой функции (`alloca'), программе (`gcc') или выходной переменной (`INSTALL').

additional-options

Конкретное поведение конкретного члена класса, к которому применяется этот тест. Например, `broken' ("сломано") или `set' ("установлено"). Эта часть имени может быть опущена.

Значения кэшированных переменных не могут содержать переводы строк. Обычно их значения являются логическими значениями (`yes' или `no') или именами файлов или функций, поэтому это ограничение не критично.

6.3.2 Кэш-файлы

Кэш-файл --- это скрипт командного процессора, который хранит результаты тестов конфигурации, проведенных на одной системе, так что они могут совместно использоваться разными скриптами настройки, или при нескольких запусках одного и того же скрипта configure. На других системах этот файл использовать бесполезно. Если содержимое этого файла по некоторым причинам является неверным, то пользователь может удалить или отредактировать его.

По умолчанию в качестве кэш-файла `configure' использует файл `./config.cache', создавая его, если он не существует. configure распознает ключ командной строки `--cache-file=file', который позволяет использовать другой кэш-файл; этот ключ используется configure, когда он вызывает скрипты configure, находящиеся в подкаталогах, так что они используют общий кэш. See section 3.5 Настройка других пакетов, находящихся в подкаталогах, где описано, как задавать подкаталоги с помощью макроса 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 8. Ручная настройка).

На отдельной системе кэш-файл постепенно будет накапливать результаты запусков скрипта configure; первоначально он вообще не будет существовать. Запуск configure объединяет новые кэшированные результаты с уже существующим кэш-файлом. Для того, чтобы сделать работу скрипта более простой, скрипт инициализации на данной машине может указать общесистемный кэш-файл, который будет использоваться вместо используемого по умолчанию, поскольку каждый раз используется один и тот же компилятор С (see section 9.5 Установка значений по умолчанию для машины). Если ваш скрипт, или макрос, вызываемые из `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)

6.4 Выдача сообщений

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

AC_MSG_RESULT([never mind, I found the BASIC compiler])

Все эти макросы являются надстройками над командой echo. Скрипты configure должны крайне редко использовать команду echo для выдачи сообщения пользователю. Использование этих макросов позволяет легко изменить способ, каким выдается каждый из типов сообщений; такие изменения можно будет внести в определение макроса, и все вызовы этого макроса изменят свой вид автоматически.

Macro: AC_MSG_CHECKING (feature-description)

Уведомляет пользователя о том, что configure проверяет конкретную возможность. Этот макрос печатает сообщение, которое начинается с `checking ' и заканчивается `...', без перехода на новую строку. Вслед за вызовом этого макроса следует использовать макрос AC_MSG_RESULT, который выдает результат проверки и символ перевода строки. Аргумент feature-description должен содержать что-нибудь типа `понимает ли компилятор Fortran комментарии в стиле C++' или `for c89'.

Этот макрос ничего не выводит, если configure запущен с ключами `--quiet' или `--silent'.

Macro: AC_MSG_RESULT (result-description)

Уведомляет пользователя о результатах проверки. Аргумент result-description почти всегда содержит значение переменной кэша для данного теста, и обычно равно `yes', `no' или имени файла. Этот макрос должен вызываться после вызова AC_MSG_CHECKING и аргумент result-description по смыслу должен дополнять сообщение, выданное вызовом AC_MSG_CHECKING.

Этот макрос ничего не выводит, если configure запущен с ключами `--quiet' или `--silent'.

Macro: AC_MSG_ERROR (error-description)

Уведомляет пользователя об ошибке, препятствующей работе configure. Этот макрос печатает сообщение об ошибке в стандартный поток вывода и заканчивает работу configure с ненулевым статусом. Аргумент error-description должен содержать что-то подобное `неправильное значение $HOME для \$HOME'.

Macro: AC_MSG_WARN (problem-description)

Уведомляет пользователя configure о возможной проблеме. Этот макрос выдает сообщение в стандартный поток сообщений об ошибках; после этого configure продолжает свое выполнение, так что макрос, вызвавший AC_MSG_WARN, должен предоставить действия по умолчанию для ситуаций, о которых он выдавал предупреждения. Аргумент problem-description должен содержать что-то подобное `кажется ln -s создает жесткие ссылки'.

Следующие два макроса устаревшие и являются альтернативой для макросов AC_MSG_CHECKING и AC_MSG_RESULT.

Macro: AC_CHECKING (feature-description)

Этот макрос подобен AC_MSG_CHECKING, но он выдает символ перевода строки после вывода feature-description. Он в основном полезен для выдачи общего описания группы проверок, например:

AC_CHECKING(if stack overflow is detectable)

Macro: AC_VERBOSE (result-description)

Этот макрос подобен AC_MSG_RESULT, но его вызов следует за вызовом AC_CHECKING, а не AC_MSG_CHECKING; выдаваемое им сообщение начинается с символа табуляции. Этот макрос считается устаревшим.