go to the first, previous, next, last section, table of contents.
@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 заголовочные файлы конфигурации, для
дополнительной информации об этом способе вывода результатов.
- 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")
@anchor{setting output variables}
одним из способов записи результатов тестов является установка
выходных переменных, то есть переменных командного
процессора, чьи значения подставляются в файлы, выводимые
configure . нижеприведенные макросы используются для создания
новых выходных переменных. see section установка выходных переменных, где
приведен список всегда присутствующих выходных переменных.
- 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@
@anchor{caching results}
чтобы избежать повторяющихся проверок одних и тех же возможностей в
различных скриптах 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 имена переменных кэша, для того чтобы узнать, как выбрать имя переменной
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'
будет прервана.
@anchor{cache variable names}
имена переменных кэша должны иметь следующий формат:
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, перечислены в
section имена макросов.
- specific-value
-
для какого члена класса кэшированных значений применяется данный тест. например,
к какой функции (`alloca'), программе (`gcc') или выходной
переменной (`install').
- additional-options
-
конкретное поведение конкретного члена класса, к которому применяется
этот тест. например, `broken' ("сломано") или `set'
("установлено"). эта часть имени может быть опущена.
значения кэшированных переменных не могут содержать переводы строк.
обычно их значения являются логическими значениями (`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 для выдачи сообщения пользователю. использование этих
макросов позволяет легко изменить способ, каким выдается каждый из типов
сообщений; такие изменения можно будет внести в определение макроса, и
все вызовы этого макроса изменят свой вид автоматически.
- 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 ; выдаваемое им сообщение начинается с символа
табуляции. этот макрос считается устаревшим.
go to the first, previous, next, last section, table of contents.
|