| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Скрипты configure поддерживают несколько видов решений
локальной конфигурации. Пользователь может указать,
где находятся внешние пакеты программного
обеспечения, включить или отключить дополнительные возможности,
установить программы, изменяя их имена, и установить значения по
умолчанию для ключей configure.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Некоторые пакеты требуют, или могут при случае использовать другие
пакеты программного обеспечения, уже установленные в
системе. Пользователь может указать скрипту 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 использовать этот
пакет. Будет ли пакет использоваться по умолчанию или нет, а также какие
аргументы будут правильны, зависит от вас.
Если пользователь задал 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 |
AC_ARG_WITH, которая не
поддерживает использование строки помощи.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Если пакет имеет необязательные возможности, задающиеся во время
компиляции, то пользователь может задать 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 включение этой возможности. Будет ли эта возможность
включена по умолчанию или нет, и какие аргументы будут правильными,
зависит от вас.
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 9.1 Работа с внешним программным обеспечением).
AC_ARG_ENABLE, которая не поддерживает
использование строки помощи.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Некоторые пакеты программ требуют сложной специфической для машины информации. Например, это имена машин, предоставляющих какие-либо сервисы, имена компаний, а также электронные почтовые адреса, по которым можно связаться с необходимыми людьми. Поскольку некоторые скрипты, созданные Metaconfig, запрашивают эту информацию интерактивно, то люди часто спрашивают, как можно получить эту информацию в Autoconf-скриптах, которые не являются интерактивными.
Такая информация по конфигурации машины должна быть помещена в файл,
редактируемый только людьми, а не программами. Файл может
располагаться либо в зависимости от значения используемой переменной
prefix, либо находиться в стандартном месте, например, в домашнем
каталоге пользователя. Он даже может быть указан в переменной
среды. Программа должна использовать этот файл во время выполнения, а не
во время компиляции. Настройка во время выполнения является более
удобной для пользователей и делает процесс настройки более простым, чем
получение информации во время процесса конфигурации. See section `Variables for Installation Directories' in GNU Coding Standards, в которых описано, где именно необходимо размещать
файлы данных.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
9.4.1 Ключи преобразования Ключи configureдля преобразования имен.9.4.2 Примеры преобразований 9.4.3 Правила преобразования `Makefile' использующий преобразование имен.
Autoconf поддерживает изменение имен программ при их установке. Для
того, чтобы использовать это преобразование, в файле `configure.in'
должен быть вызов макроса AC_ARG_PROGRAM.
program_transform_name
последовательность команд sed, используемых для изменения имен
устанавливаемых программ.
Если при запуске configure задан любой из нижеописанных ключей,
то имена программ изменяются соответствующим образом. В противном
случае, если был вызван макрос AC_CANONICAL_SYSTEM и значение,
заданное с помощью ключа `--target' отличается от типа машины,
(указанного с помощью ключа `--host' или типа по умолчанию,
определенного с помощью config.sub), то в качестве префикса имени
используется тип целевой машины и дефис. Если не задано ни того, ни
другого, то преобразование имен не выполняется.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Вы можете задать преобразование имен, запустив configure со
следующими ключами командной строки:
--program-prefix=prefix
--program-suffix=suffix
--program-transform-name=expression
sed expression для имен программ.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Эти преобразования полезны при работе с программами, которые являются частью кросс-компиляционной среды разработки. Например, кросс-ассемблер, запускаемый на 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/' |
gdb, чьи имена уже
начинаются с этого символа, и за исключением less и lesskey,
которые не являются программами GNU. (Предполагается, что дерево
исходных текстов, содержащее эти программы, уже сконфигурировано для
использования этой возможности).
Одним из способов одновременной установки нескольких версий некоторых программ является добавление номера версии программы к имени. Например, если вы хотите сохранить для дальнейшего использования Autoconf версии 1, то вы можете настроить Autoconf версии 2 с помощью ключа `--program-suffix=2' для того, чтобы программы были установлены под именами `/usr/local/bin/autoconf2', `/usr/local/bin/autoheader2' и т. п.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Вот как нужно использовать переменную 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Созданные 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
|
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |