| |
@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.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |