Go to the
first,
previous,
next,
last section,
table of contents.
@anchor{Site Configuration}
Скрипты configure поддерживают несколько видов решений
локальной конфигурации. Пользователь может указать,
где находятся внешние пакеты программного
обеспечения, включить или отключить дополнительные возможности,
установить программы, изменяя их имена, и установить значения по
умолчанию для ключей configure.
@anchor{External Software}
Некоторые пакеты требуют, или могут при случае использовать другие
пакеты программного обеспечения, уже установленные в
системе. Пользователь может указать скрипту configure с помощью ключей
командной строки, какие внешние пакеты надо
использовать. Ключи имеют одну из следующих форм:
--with-package[=arg]
--without-package
Например, `--with-gnu-ld' означает, что надо работать с
компоновщиком GNU linker вместо других компоновщиков. `--with-x'
означает работу с X Window System.
Пользователь может задать аргумент, поставив после имени пакета символ
`=' и нужный аргумент. Вы можете задать аргумент, равный `no' для
пакетов, которые используются по умолчанию; он сообщает о том, что этот
пакет не надо использовать. Аргумент, который не равен ни
`yes', ни `no', может включать имя или номер версии другого
пакета, для более точного указания, с каким пакетом эта программа
предполагает работать. Если аргумент не задан, то его значение по
умолчанию равно `yes'. `--without-package' эквивалентно
вызову `--with-package=no'.
Скрипты configure не выдают ошибок о ключах
`--with-package', которые они не поддерживают. Такое
поведение позволяет конфигурировать дерево исходных текстов, содержащее
множество пакетов, с помощью скрипта configure верхнего уровня,
когда пакеты поддерживают разные ключи, без выдачи фальшивых сообщений
об ошибках в ключах, которые поддерживают лишь некоторые пакеты. К
сожалению, побочным эффектом
этого является то, что ошибка в задании ключей не диагностируется. До
сих пор не было предложено лучшего подхода к решению этой проблемы.
Для каждого из внешних пакетов, который может быть использован в файле
`configure.in', должен быть вызван макрос AC_ARG_WITH для
определения того, заставил ли пользователь configure использовать
этот пакет. Будет ли пакет использоваться по умолчанию или нет, а также
то, какие аргументы будут правильны, зависит от вас.
- Macro: AC_ARG_WITH (package, help-string [, action-if-given [, action-if-not-given]])
-
Если пользователь задал
configure ключ
`--with-package' или ключ `--without-package', то
выполняются команды командного процессора action-if-given. Если ни
один из ключей не задан, то выполняются команды
action-if-not-given. Имя package задает другой пакет, с
которым должна работать эта программа. Это имя должно содержать только
буквы, цифры и знаки минус.
Аргумент ключа командной строки из кода командного процессора
action-if-given в переменной командного процессора withval,
который в действительности является значением переменной командного
процессора with_package, с символами `-', замененными
на символ `_'. Можете использовать эту переменную, если хотите.
Аргумент help-string является описанием ключа, который выглядит
примерно так:
--with-readline support fancy command line editing
help-string может занимать больше одной строки, если
необходима подробная информация. Просто убедитесь, что строка разделена
на колонки в выводе `configure --help'. Избегайте использовать
символы табуляции в строке помощи. Для того, чтобы сохранить начальные
пробелы, нужно поместить строку между символами `[' и `]'.
- Macro: AC_WITH (package, action-if-given [, action-if-not-given])
-
Это устаревшая версия макроса
AC_ARG_WITH, которая не
поддерживает использование строки помощи.
@anchor{Package Options}
Если пакет имеет необязательные возможности, которые задаются во время компиляции, то
пользователь может задать configure ключи командной строки для
указания--- нужно ли их компилировать. Ключи имеют одну из следующих
форм:
--enable-feature[=arg]
--disable-feature
Эти ключи позволяют пользователю выбрать, какие необязательные возможности
нужно собрать и установить. Ключи `--enable-feature' никогда
не должны приводить к тому, что какое-то свойство изменит свое
поведение, или же заменять одну возможность другой. Эти ключи должны
только включать или не включать части программы в процесс компиляции.
Пользователь может задать аргумент, который следует за именем свойства и
знаком `='. Если задать аргумент `no', то свойство будет
недоступным. Свойство с аргументом может выглядеть
примерно следующим образом: `--enable-debug=stabs'. Если
аргумента не задано, то значением по умолчанию является `yes'.
`--disable-feature' является эквивалентом
`--enable-feature=no'.
Скрипты configure не выражают недовольства по поводу ключей
`--enable-feature', которые они не поддерживают. Такое
поведение позволяет конфигурировать дерево исходных текстов, содержащее
множество пакетов, с помощью скрипта configure верхнего уровня,
когда пакеты поддерживают разные ключи, без выдачи фальшивых сообщений
об ошибках о ключах, которые поддерживают только некоторые пакеты. Побочным эффектом
этого является то, что ошибка в задании ключей не диагностируется. До
сих пор не было предложено лучшего подхода к решению этой проблемы.
Для каждой из необязательных возможностей `configure.in' должен вызывать
AC_ARG_ENABLE для определения, запросил ли пользователь
configure включить эту возможность. Будет ли эта возможность включена
по умолчанию или нет, и какие аргументы будут правильными, зависит от
вас.
- Macro: AC_ARG_ENABLE (feature, help-string [, action-if-given [, action-if-not-given]])
-
Если пользователь задал
configure ключ
`--enable-feature' или `--disable-feature', то
запускаются команды action-if-given. Если не был задан ни один
ключ, то запускаются команды action-if-not-given. Имя
feature указывает необязательную возможность, которую пользователь
может включить или выключить. Имя должно состоять только из букв, цифр
и знаков "минус".
Аргумент ключа доступен из кода командного процессора action-if-given
в переменной командного процессора enableval, которая в
действительности является значением переменной
enable_feature, причем символы `-' заменены на символ
`_'. Если хотите, то можете использовать эту переменную.
Аргумент help-string делает то же самое, что и соответствующий аргумент макроса
AC_ARG_WITH (see section Работа с внешним программным обеспечением).
- Macro: AC_ENABLE (feature, action-if-given [, action-if-not-given])
-
Это устаревшая версия
AC_ARG_ENABLE, которая не поддерживает
использование строки помощи.
@anchor{Site Details}
Некоторые пакеты программ требуют сложной специфической для машины
информации. Например, это имена машин, предоставляющих какие-либо
сервисы, имена компаний, а также
электронные почтовые адреса, по которым можно связаться с какими-то
людьми. Поскольку некоторые скрипты, созданные Metaconfig, запрашивают эту
информацию интерактивно, то люди часто спрашивают, как можно получить эту
информацию в Autoconf-скриптах, которые не являются
интерактивными.
Такая информация по конфигурации машины должна быть помещена в файл,
редактируемый только людьми, а не программами. Файл может
располагаться либо в зависимости от значения используемой переменной
prefix, либо находиться в стандартном месте, например, в
домашнем каталоге пользователя. Он даже может быть указан в переменной
среды. Программа должна использовать этот файл во время выполнения, а не
во время компиляции. Настройка во время выполнения является более
удобной для пользователей и делает процесс настройки более простым, чем
получение информации во время процесса конфигурации. See section `Variables for Installation Directories' in GNU Coding Standards, где описано, где именно необходимо размещать
файлы данных.
@anchor{Transforming Names}
Autoconf поддерживает изменение имен программ при их установке. Для
того, чтобы использовать это преобразование, в файле `configure.in'
должен быть вызов макроса AC_ARG_PROGRAM.
- Macro: AC_ARG_PROGRAM
-
Помещает в выходную переменную
program_transform_name
последовательность команд sed, используемых для изменения имен
устанавливаемых программ.
Если при запуске configure задан любой из нижеописанных ключей,
то имена программ изменяются соответствующим образом. В противном
случае, если был вызван макрос AC_CANONICAL_SYSTEM и значение,
заданное с помощью ключа `--target' отличается от типа машины, (указанного с помощью
ключа `--host' или типа по умолчанию, определенного с помощью
config.sub), то в качестве префикса имени используется тип
целевой машины и дефис. Если не задано ни того, ни другого, то
преобразование имен не выполняется.
@anchor{Transformation Options}
Вы можете задать преобразование имен, запустив configure со
следующими ключами командной строки:
--program-prefix=prefix
-
добавляет префикс prefix к именам;
--program-suffix=suffix
-
добавляет к именам суффикс suffix;
--program-transform-name=expression
-
выполняет подстановки
sed expression для имен программ.
@anchor{Transformation Examples}
Эти преобразования полезны при работе с программами, которые являются частью
кросс-компиляционной среды разработки. Например, кросс-ассемблер,
запускаемый на Sun 4 и настроенный с ключом `--target=i960-vxworks'
обычно устанавливается как `i960-vxworks-as', а не как `as',
иначе его можно перепутать с родным ассемблером Sun 4.
Можно сделать так, чтобы имена программ начинались с символа `g',
если не хотите, чтобы программы GNU, установленные в системе, заслоняли собой
другие утилиты с тем же именем. Например, если вы настраиваете программу
GNU diff с ключом `--program-prefix=g', то затем вы можете
запустить `make install' и программа будет установлена как
`/usr/local/bin/gdiff'.
В качестве более изощренного примера вы можете использовать
--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
для добавления символа `g' к большинству имен программ в дереве
исходных текстов, за исключением программ типа gdb, чьи имена уже
начинаются с этого символа, и за исключением less и lesskey,
которые не являются программами GNU. (Предполагается, что дерево
исходных текстов, содержащее эти программы, уже сконфигурировано для
использования этой возможности).
Одним из способов одновременной установки нескольких версий некоторых
программ является добавление номера версии программы к имени. Например,
если вы хотите сохранить для дальнейшего использования Autoconf версии
1, то вы можете настроить Autoconf версии 2 с помощью ключа
`--program-suffix=2' для того, чтобы программы были установлены под
именами `/usr/local/bin/autoconf2',
`/usr/local/bin/autoheader2' и т. п.
@anchor{Transformation Rules}
Вот как нужно использовать переменную program_transform_name в
`Makefile.in':
transform=@program_transform_name@
install: all
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`
uninstall:
rm -f $(bindir)/`echo myprog|sed '$(transform)'`
Если у вас устанавливается больше одной программы, то вы можете
выполнять ту же операцию в цикле:
PROGRAMS=cp ls rm
install:
for p in $(PROGRAMS); do \
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
done
uninstall:
for p in $(PROGRAMS); do \
rm -f $(bindir)/`echo $$p|sed '$(transform)'`; \
done
Преобразовывать ли имена файлов документации (Texinfo или man) --
сложный вопрос. Кажется, на него нет единственного ответа, потому что
для преобразования имен есть несколько причин. Часто
документация не является специфической для конкретной архитектуры, а
файлы Texinfo не конфликтуют с системной документацией. Но эти файлы
иногда могут конфликтовать с ранними версиями тех же файлов, а страницы
man иногда могут конфликтовать с системной документацией. В
качестве компромисса, можно выполнять преобразования имен страниц
man, но не руководств в формате Texinfo.
@anchor{Site Defaults}
Созданные Autoconf скрипты configure позволяют вам задать
значения по умолчанию для некоторых параметров настройки. Вы можете
сделать это, создавая файлы инициализации для машины и для целой
системы.
Если установлена переменная среды CONFIG_SITE, то
configure использует ее значение как имя скрипта командного
процессора, который необходимо выполнить. В противном случае он считывает
скрипт `prefix/share/config.site', если тот
существует, а затем скрипт `prefix/etc/config.site', также
если он существует. Таким образом, специфические для машины файлы
перекрывают настройки в машинно-независимых файлах в случае конфликта.
Файлы настроек машины могут быть произвольными скриптами командного
процессора, но реально использоваться в них могут только определенные
строки кода. Поскольку configure считывает кэш-файлы
после того, как он считывает файлы настройки машины, то файл локальной
конфигурации может определить кэш-файл по умолчанию, который будет общим для всех
запускаемых в системе скриптов configure, которые созданы с
помощью Autoconf. Если вы установите кэш-файл по умолчанию в файле
локальной настройки, то хорошо было бы установить также выходную
переменную CC, поскольку кэш-файл
является правильным только для определенного компилятора, а многие
системы имеют несколько компиляторов.
В файле локальных настроек вы можете проверять или изменять значения
ключей командной строки, заданных скрипту configure; ключи
устанавливают переменные командного процессора, которые называются так же,
как и ключи командной строки, но с символами дефиса, замененными на
символы
подчеркивания. Исключением из этого правила являются ключи
`--without-' и `--disable-', которые подобны заданию
соответствующих ключей `--with-' или `--enable-' со значением
`no'. Таким образом, `--cache-file=localcache' устанавливает
переменную cache_file в значение `localcache';
`--enable-warnings=no' или `--disable-warnings' устанавливают
переменную enable_warnings равной значению `no';
`--prefix=/usr' устанавливает переменную prefix равной
`/usr'; и т. п.
В файлах локальных настроек также можно устанавливать нестандартные
значения по умолчанию для других выходных переменных, таких как
CFLAGS: иначе вам пришлось бы делать это снова и снова в
командной строке. Если вы обычно используете нестандартные значения для
переменных prefix или exec_prefix (которые обычно
используются для указания файла локальной конфигурации), то все равно
можно задать эти значения в этом файле, если указать его имя в
переменной среды CONFIG_SITE.
Вы можете сами установить значения некоторых кэш-переменных в файле
локальной конфигурации. Это полезно делать при кросс-компиляции, поскольку
невозможно определить проверить возможности, которые требуют запуска
тестовых программ. Вы можете "заполнить кэш" установкой этих значений
для этих систем в файле `prefix/etc/config.site'. Для
определения имен кэш-переменных, которые вам необходимо установить,
поищите переменные с именами, содержащими `_cv_' в соответствующих
скриптах configure или в исходном коде m4 макросов
Autoconf.
Кэш-файл не переопределяет ни одну переменную, установленную в файлах
локальной конфигурации. Сходным образом вы не должны переопределять ключи
командной строки в файлах локальной конфигурации. Ваш код должен
проверять, имеют ли уже переменные типа prefix или
cache_file значения по умолчанию (установленные ранее в процессе
выполнения configure), и если да, то не изменять этих значений.
Вот пример файла `/usr/share/local/gnu/share/config.site'.
Команда `configure --prefix=/usr/share/local/gnu' должна прочитать
этот файл (если переменная CONFIG_SITE не
установлена в другое значение).
# config.site для configure
#
# изменение некоторых значений по умолчанию.
test "$prefix" = NONE && prefix=/usr/share/local/gnu
test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
test "$localstatedir" = '${prefix}/var' && localstatedir=/var
#
# разрешить скриптам, созданным Autoconf 2.x, пользоваться общим кэш-файлом
# для получения результатов тестов, которые действительны для данной
# архитектуры.
if test "$cache_file" = ./config.cache; then
cache_file="$prefix/var/config.cache"
# Кэш-файл действителен только для одного компилятора C.
CC=gcc
fi
Go to the first, previous, next, last section, table of contents.
