@dircategory GNU admin * automake: (automake). Создание Makefile.in
@dircategory Отдельные утилиты * aclocal: (automake)Запуск aclocal. Создание aclocal.m4
Авторские права (C) 1995, 96 Free Software Foundation, Inc.
Это первая редакция документации по GNU Automake,
и она согласована с GNU Automake 1.4.
Published by the Free Software Foundation
59 Temple Place - Suite 330,
Boston, MA 02111-1307 USA
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
Automake---это утилита для автоматической генерации файлов
`Makefile.in' из файлов `Makefile.am'. Каждый файл
`Makefile.am' является набором макросов для программы make
(с определенными правилами). Сгенерированные файлы `Makefile.in'
соответствуют стандартам GNU Makefile.
Стандарт GNU Makefile (see section `Makefile Conventions' in The GNU Coding Standards)---это длинный, запутанный документ, который может изменяться в будущем. Automake разработан для того, чтобы убрать груз сопровождения Makefile со спины отдельного человека, сопровождающего конкретный проект GNU (и поместить этот груз на человека, сопровождающего Automake).
Типичный входной файл Automake является просто набором макроопределений. Каждый такой файл обрабатывается, и из него создается файл `Makefile.in'. В общем случае в каталоге проекта должен быть один файл `Makefile.am'.
Automake ограничивает проект несколькими способами; например он предполагает, что проект использует программу Autoconf (see section `Introduction' in The Autoconf Manual), а также требует некоторых ограничений на содержимое файла `configure.in'.
Automake требует наличия программы perl для генерации файлов
`Makefile.in'. Однако дистрибутив, созданный Automake является
полностью соответствующим стандартам GNU и не требует наличия программы
perl для своего построения.
Вы можете посылать пожелания по доработке и сообщения об ошибках Automake на адрес bug-automake@gnu.org.
Следующие разделы описывают основные идеи, которые вам помогут понять как работает Automake.
Automake работает, считывая файл `Makefile.am' и создавая файл `Makefile.in'. Специальные макросы и цели, определенные в `Makefile.am' заставляют Automake генерировать более специализированный код; например, макроопределение `bin_PROGRAMS' заставит сгенерировать цели для компиляции и компоновки программ.
Макроопределения и цели из файла `Makefile.am' без изменений
копируются в сгенерированный файл. Это позволяет вам добавить
произвольный код в сгенерированный файл `Makefile.in'. Например
дистрибутив Automake включает в себя нестандартную цель cvs-dist,
которую использует человек, сопровождающий Automake, для создания
дистрибутивов из системы контроля исходного кода.
Заметьте, что расширения GNU make не распознаются программой Automake. Использование таких расширений в файле `Makefile.am' приведет к ошибкам, или странному поведению.
Automake пытается сгруппировать комментарии для расположенных рядом целей и макроопределений.
Цели, определенные в `Makefile.am' обычно переопределяют цели с
таким же именем, которые автоматически генерируются
automake. Хотя это свойство поддерживается, но старайтесь
избегать его использования, поскольку иногда сгенерированные цели
являются очень важными.
Аналогичным образом, макросы определенные в `Makefile.am' будут
переопределять макросы, создаваемые программой automake. Часто
это свойство более полезно, чем возможность переопределения цели. Но
будьте осторожны, поскольку многие из макросов, создаваемых программой
automake считаются макросами только для внутреннего
использования, и их имена могут измениться в будущих выпусках.
При рассмотрении макроопределения, Automake будет рекурсивно
рассматривать макросы, на которые есть ссылка в данном
макроопределении. Например, если Automake исследует содержимое
определения foo_SOURCES
xs = a.c b.c foo_SOURCES = c.c $(xs)
то он будет использовать файлы `a.c', `b.c' и `c.c' как
содержимое foo_SOURCES.
Automake также вводит форму комментария, который не копируется в выходной файл; все строки, начинающиеся с `##' полностью игнорируются Automake.
Очень часто первая строка файла `Makefile.am' выглядит следующим образом:
## Process this file with automake to produce Makefile.in ## Для получения Makefile.in обработайте этот файл программой automake
automake поддерживает три типа иерархии каталогов: `flat',
`shallow' и `deep'.
Тип пакета flat---это когда все файлы пакета располагаются в одном
каталоге. В файле `Makefile.am' для этого типа пакета отсутствует
макрос SUBDIRS. Примером такого пакета может служить пакет
termutils.
Тип пакета deep предполагает, что все исходные тексты лежат в
подкаталогах; каталог верхнего уровня содержит в основном
конфигурационную информацию. Хорошим примером такого пакета является GNU
cpio, так же как и GNU tar. Файл `Makefile.am' в
каталоге верхнего уровня будет содержать макрос SUBDIRS, но не
будет содержать макросы для определения объектов, которые надо
построить.
Тип пакета shallow---это когда основные файлы исходных текстов
располагаются в каталоге верхнего уровня, а различные части этого пакета
(обычно библиотеки) располагаются в подкаталогах. К пакетам такого типа
относится Automake (а также GNU make, который в настоящее время
не использует automake).
Хотя Automake и предназначен для использования людьми, сопровождающими пакеты GNU, он также прилагает некоторые усилия для того, чтобы приспособиться к тем, кто хочет использовать Automake, но не хочет использовать все соглашения GNU.
Сейчас Automake поддерживает три уровня ограничений (strictness)---ограничение показывает как строго Automake должен проверять соответствие стандартам.
Ограничение может принимать следующие значения:
Для более детальной информации о точном смысле уровня ограничений смотрите
section Эффект --gnu и --gnits.
Макросы Automake (с этого места мы будем ссылаться на них как на
переменные) в общем следуют единообразной схеме наименования,
которая позволяет легко понять как собираются программы (и другие
унаследованные объекты), и как они устанавливаются. Эта схема также
поддерживает определение того, что должно быть собрано во время выполнения
configure.
Во время выполнения make, используются некоторые переменные для
определения того, что должно быть собрано. Эти переменный называются
основными переменными. Например, основаня переменная PROGRAMS
содержит список программ, которые должны быть откомпилированы и собраны.
Различный набор переменных используется для принятия решения о том, куда
должны быть установлены собранные объекты. Эти переменные называются
подобно основным переменным, но имеют префикс, указывающий какой из
стандартных каталогов должен быть использован как каталог для установки.
Имена стандартных каталогов определены в стандартах GNU
(see section `Directory Variables' in The GNU Coding Standards). Automake расширяет это список переменными pkglibdir,
pkgincludedir и pkgdatadir; которые имеют те же значения,
что и не-`pkg' версии, но с прибавленным к ним
`@PACKAGE@'. Например, pkglibdir определена как
$(datadir)/@PACKAGE@.
Для каждой из основных переменных, также существует дополнительная
переменная, имя которой образовано добавлением префикса `EXTRA_' к
имени основной переменной. Эта переменная используется для перечисления
объектов, которые могут быть собраны, а могут быть и не собраны в
зависимости от принятого configure решения. Эти переменные
требуются, поскольку Automake должен обязательно знать полный список
объектов, которые должны быть собраны, для того чтобы создать
`Makefile.in', работающий в любых ситуациях.
Например пакет, cpio принимает решение во время конфигурации,
какие программы необходимо построить. Некоторые программы
устанавливаются в bindir, а некоторые в sbindir:
EXTRA_PROGRAMS = mt rmt bin_PROGRAMS = cpio pax sbin_PROGRAMS = @PROGRAMS@
Определение основной переменной без префикса (например. PROGRAMS)
является ошибкой.
Заметьте, что общий суффикс `dir' опускается при создании имен переменных; таким образом имя переменной записывается как `bin_PROGRAMS', а не `bindir_PROGRAMS'.
Не каждый тип объектов может быть установлен в каждый каталог. Automake будет считать такие попытки как ошибку. Automake также будет диагностировать очевидные ошибки в именах каталогов.
Иногда стандартных каталогов---даже как аргументировано Automake---не
достаточно. В частности это иногда полезно, для ясности, для установки
объектов в подкаталог какой-то предопределенного каталога. Здесь
Automake также позволяет нам расширить список возможных каталогов для
установки. Заданный префикс (например `zar') является возможным,
если определена переменная имеющая то же имя, только со словом
`dir' добавленным к ее концу (например zardir).
Например пока поддержка HTML не станет частью Automake, вы должны использовать этот пример для установки документации в формате HTML:
htmldir = $(prefix)/html html_DATA = automake.html
Специальный префикс `noinst' показывает, что объекты не должны устанавливаться.
Специальный префикс `check' показывает, что указанные объекты не
должны быть построены до того, пока не будет запущена команда make
check.
Возможными основными именами являются `PROGRAMS', `LIBRARIES', `LISP', `SCRIPTS', `DATA', `HEADERS', `MANS' и `TEXINFOS'.
Иногда имена переменных в Makefile образуются на базе некоторого текста,
заданного пользователем. Например, имена программ перезаписаны в имена
макросов Makefile. Automake канонизирует этот текст, так что он не
должен следовать правилам именования макросов Makefile. Все имена в
имени, за исключением букв, чисел, и подчеркиваний, преобразуются в
подчеркивания при создании ссылки на макрос. Например, если ваша
программа названа sniff-glue, то имена унаследованных переменных
должны быть sniff_glue_SOURCES, а не sniff-glue_SOURCES.
Давайте предположим, что мы только что закончили писать
zardoz---программу, которая заставляет (???your head float from
vortex to vortex). Вы использовали Autoconf для обеспечения
переносимости, но ваш файл `Makefile.in' был специализированным
(??ручной работы). Вы хотите сделать его более устойчивым
(пуленепробиваемым), так что вы обращаетесь к использованию to Automake.
Сначала вам необходимо обновить ваш файл `configure.in', для того,
чтобы вставить в него команды которые необходимы для работы
automake. Самым простым способом сделать это является добавление
вызова AM_INIT_AUTOMAKE сразу после AC_INIT:
AM_INIT_AUTOMAKE(zardoz, 1.0)
Поскольку ваша программа не имеет никаких осложняющих факторов (например
она не использует gettext, она не будет создавать разделяемые
библиотеки), вы работаете только эту часть. Это легко!
Теперь вы должны перегенерировать ваш файл `configure'. Но, чтобы
сделать это, вам необходимо сообщить autoconf, как найти новые
макросы в которых он нуждается. Для создания вашего файла
`aclocal.m4' самым удобным будет использование программы
aclocal. Но будьте осторожны... у вас уже есть
`aclocal.m4', поскольку вы уже написали несколько собственных
макросов для вашей программы. Программа aclocal позволяет вам
поместить ваши собственные макросы в файл `acinclude.m4', так что
для сохранения вашей работы просто переименуйте свой файл с макросами, а
уж затем уже запускайте программу aclocal:
mv aclocal.m4 acinclude.m4 aclocal autoconf
Теперь пришло время написать ваш собственный файл `Makefile.am' для
программы zardoz. Поскольку zardoz является
пользовательской программой, то вам хочется установить ее туда, где
располагаются другие пользовательские программы. Также, zardoz
имеет в своем составе документацию в формате Texinfo. Ваш скрипт
`configure.in' использует AC_REPLACE_FUNCS, так что вам
необходимо скомпоновать программу с `@LIBOBJS@'. Вот что вам
необходимо написать в `Makefile.am'.
bin_PROGRAMS = zardoz zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c zardoz_LDADD = @LIBOBJS@ info_TEXINFOS = zardoz.texi
Теперь вы можете запустить automake --add-missing для создания
вашего собственного `Makefile.in' и взять любые дополнительные
файлы, в которых вы нуждаетесь, и все будет сделано!
GNU hello известен за свою классическую простоту и многогранность. В этом разделе показывается как Automake может быть использован с пакетом GNU Hello. Примеры, приведенные ниже взяты из последней бета-версии GNU Hello, но откинут код, предназначенный только для человека сопровождающего пакет, а также сообщения об авторских правах.
Конечно GNU Hello использует больше возможностей, чем традиционная двухстроковая программа: GNU Hello работает с разными языками, выполняет обработку ключей командной строки, имеет документацию и тестовую часть. GNU Hello является пакетом типа deep.
Вот файл `configure.in' из пакета GNU Hello:
dnl Обработайте этот файл программой autoconf для создания скрипта configure.
AC_INIT(src/hello.c)
AM_INIT_AUTOMAKE(hello, 1.3.11)
AM_CONFIG_HEADER(config.h)
dnl Набор доступных языков.
ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
dnl Проверка наличия программ.
AC_PROG_CC
AC_ISC_POSIX
dnl Проверка имеющихся библиотек.
dnl Проверка наличия заголовочных файлов.
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.h fcntl.h sys/file.h sys/param.h)
dnl Проверка библиотечных функций.
AC_FUNC_ALLOCA
dnl Проверка наличия поля st_blksize в структуре stat
AC_ST_BLKSIZE
dnl Макросы поддержки языков
AM_GNU_GETTEXT
AC_OUTPUT([Makefile doc/Makefile intl/Makefile po/Makefile.in \
src/Makefile tests/Makefile tests/hello],
[chmod +x tests/hello])
Макросы `AM_' предоставляются Automake (или библиотекой Gettext); остальные макросы является макросами Autoconf.
Файл `Makefile.am' в корневом каталоге выглядит следующим образом:
EXTRA_DIST = BUGS ChangeLog.O SUBDIRS = doc intl po src tests
Как вы видите, вся работа выполняется в подкаталогах.
Каталоги `po' и `intl' автоматически создаются программой
gettextize; они не будут обсуждаться в этом документе.
В файле `doc/Makefile.am' мы увидим строки:
info_TEXINFOS = hello.texi hello_TEXINFOS = gpl.texi
Этого достаточно для оборки, установки и распространения руководства GNU Hello.
Вот содержимое файла `tests/Makefile.am':
TESTS = hello EXTRA_DIST = hello.in testdata
Скрипт `hello' создается configure, и является только
тестовым. При выполнении make check этот тест будет запущен.
В заключение мы приведем содержимое `src/Makefile.am', где и выполняется вся настоящая работа:
bin_PROGRAMS = hello hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h hello_LDADD = @INTLLIBS@ @ALLOCA@ localedir = $(datadir)/locale INCLUDES = -I../intl -DLOCALEDIR=\"$(localedir)\"
Вот другой, более изощренный пример. Он показывает, как собрать две
программы (ctags и etags) из одного и того же файла
исходного текста (`etags.c'). Самая трудное в том, что каждая
компиляция файла `etags.c' требует задания разных флагов для
cpp.
bin_PROGRAMS = etags ctags
ctags_SOURCES =
ctags_LDADD = ctags.o
etags.o: etags.c
$(COMPILE) -DETAGS_REGEXPS -c etags.c
ctags.o: etags.c
$(COMPILE) -DCTAGS -o ctags.o -c etags.c
Заметьте, что переменная ctags_SOURCES определена как пустая---в
этом случае никакая переменная не подставляется. Для создания
etags из файла `etags.o' используются неявные значения.
Переменная ctags_LDADD используется для вставки `ctags.o' в
строку компоновщика. ctags_DEPENDENCIES создается Automake.
Вышеприведенные правила не работают в том случае, если ваш компилятор не
умеет одновременно работать с ключами `-c' и `-o'. Самым
простым способом исправить это недоразумение является введение
поддельной зависимости (для того, чтобы избежать проблем с параллельной
версией make):
etags.o: etags.c ctags.o
$(COMPILE) -DETAGS_REGEXPS -c etags.c
ctags.o: etags.c
$(COMPILE) -DCTAGS -c etags.c && mv etags.o ctags.o
Эти явные правила также не работают, если используется де-ANSI-фикация (see section Автоматическая де-ANSI-фикация). Поддержка де-ANSI-фикации требует немного больше работы:
etags._o: etags._c ctags.o
$(COMPILE) -DETAGS_REGEXPS -c etags.c
ctags._o: etags._c
$(COMPILE) -DCTAGS -c etags.c && mv etags._o ctags.o
Для создания всех файлов `Makefile.in' пакета запустите программу
automake в каталоге вехнего уровня без
аргументов. automake автоматически создаст соответствующий файл
`Makefile.am' (путем сканирования `configure.in';
see section Сканирование `configure.in') и сгенерирует соответствующий файл
`Makefile.in'. Заметьте, что automake имеет более простое
видение структуры пакета; он предполагает, что пакет имеет только один
файл `configure.in', расположенный в каталоге верхнего уровня. Если
в вашем пакете имеется несколько файлов `configure.in', то вам
необходимо запустить automake в каждом из каталогов, где есть
файл `configure.in'.
Также вы можете задать аргумент для automake; суффикс `.am'
добавляется к аргументу и результат используется как имя файла ввода. В
основном это свойство используется для автоматической перегенерации
устаревших файлов `Makefile.in'. Заметьте, что automake
всегда должен запускаться из каталога верхнего уровня проекта, даже если
необходимо перегенерировать `Makefile.in' в каком-то из
подкаталогов. Это необходимо, так как automake должен
просканировать файл `configure.in', а также потому, что
automake знает, что в некоторых случаях `Makefile.in' в
подкаталоге может изменить свое поведение.
automake принимает следующие ключи командной строки:
AC_CANONICAL_HOST, то требуется наличие файла
`config.guess'. Automake распространяется с некоторыми из этих
файлов; этот ключ заставит программу автоматически добавить к пакету
отсутствующие файлы, если это возможно. В общем, если Automake сообщает
вам об отсутствии файла, то используйте этот ключ. По умолчанию Automake
пытается создать символьную ссылку на свою собственную копию
отсутствующего файла; это поведение может быть изменено использованием
ключа --copy.
make dist; он не должен использоваться в
других случаях.
--add-missing, заставляет копировать
недостающие файлы. По умолчанию создаются символьные ссылки.
--cygnus.
--gnu и --gnits.
--gnu и --gnits. Это ограничение по умолчанию.
automake создает все файлы `Makefile.in', указанные в
`configure.in'. Этот ключ заставляет обновлять только те файлы
`Makefile.in', которые устарели, с учетом зависимостей друг от
друга.
make dist; он не
должен использоваться в других случаях.
Для определения разной информации о данном пакете Automake сканирует
файл `configure.in' текущего пакета. Также ему требуется
определение некоторых макросов и переменных autoconf из файла
`configure.in'. Automake использует информацию из файла
`configure.in' для определения параметров вывода.
Для того, чтобы сделать сопровождение более легким Automake
предоставляет некоторые макросы Autoconf. Эти макросы могут быть
автоматически помещены в ваш файл `aclocal.m4' при использовании
программы aclocal.
Чтобы ознакомиться с основными требованиями Automake можно использовать
макрос AM_INIT_AUTOMAKE (see section Макросы Autoconf, поставляемые с Automake). Но если вы хотите, то
вы можете выполнить требуемые для работы этапы вручную:
PACKAGE и VERSION с
AC_SUBST.
Переменная PACKAGE должна содержать имя пакета, в таком виде как
оно появится при создании дистрибутива. Например, Automake определяет
переменную PACKAGE со значением `automake'. Переменная
VERSION должна содержать номер разрабатываемой версии. Мы
рекомендуем, чтобы вы помещали `configure.in' в только те места
пакета, где определен номер версии; это делает выпуски более простыми.
Automake не производит никакой интерпретации переменных PACKAGE
или VERSION, за исключением работы в режиме `Gnits'
(see section Эффект --gnu и --gnits).
AC_ARG_PROGRAM. See section `Преобразование имен при установке' in Autoconf.
AC_PROG_MAKE_SET если пакет не является
пакетом типа flat. See section `Создание файлов вывода' in Руководство Autoconf.
AM_SANITY_CHECK для того, чтобы убедиться, что
среда в которой будет производится сборка пакета является нормальной.
AC_PROG_INSTALL (see section `Проверка отдельных программ Program Checks' in Руководство Autoconf).
AM_MISSING_PROG для того, чтобы убедиться, что
программы aclocal, autoconf, automake,
autoheader и makeinfo находятся в среде в которой
производится сборка пакета. Вот как это сделано:
missing_dir=`cd $ac_aux_dir && pwd` AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir) AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir) AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir) AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
Вот список других макросов, которые требуются Automake, но которые не
запускаются макросом AM_INIT_AUTOMAKE:
AC_OUTPUT
Makefile относятся к файлам `Makefile'. Остальные
перечисленные файлы интерпретируются по разному. В настоящее время
отличие состоит лишь в том, что `Makefile' удаляется make
distclean, а другие файлы удаляются командой make clean.
Также Automake распознает использование некоторых макросов и соответственно им генерирует `Makefile.in'. В настоящее время он распознает следующие макросы и их эффектом являются:
AC_CONFIG_HEADER
AM_CONFIG_HEADER, который
похож на AC_CONFIG_HEADER (see section `Configuration Header Files' in The Autoconf Manual), но кроме
этого выполняет полезную работу, которая специфична для Automake.
AC_CONFIG_AUX_DIR
AC_PATH_XTRA
AC_PATH_XTRA.
See section `Системные сервисы' in Руководство Autoconf.
AC_CANONICAL_HOST
AC_CHECK_TOOL
AC_CANONICAL_SYSTEM
AC_CANONICAL_HOST, но кроме этого он
определяет переменные `build_alias' и `target_alias' для
файла `Makefile'. See section `Получение канонического типа системы' in Руководство Autoconf.
AC_FUNC_ALLOCA
AC_FUNC_GETLOADAVG
AC_FUNC_MEMCMP
AC_STRUCT_ST_BLOCKS
AC_FUNC_FNMATCH
AM_FUNC_STRTOD
AC_REPLACE_FUNCS
AC_REPLACE_GNU_GETOPT
AM_WITH_REGEX
automake -a не установит эти исходные
тексты. Для дополнительной информации See section Построение библиотеки. Также смотрите
section `Проверка отдельных функций' in Руководство Autoconf.
LIBOBJS
LIBOBJS, и будет обрабатывать эти дополнительные файлы так,
как будто они описываются через AC_REPLACE_FUNCS. See section `Проверка базовых функций' in Руководство Autoconf.
AC_PROG_RANLIB
AC_PROG_CXX
AC_PROG_F77
AC_F77_LIBRARY_LDFLAGS
AM_PROG_LIBTOOL
libtool (see section `Введение' in Руководство Libtool).
AC_PROG_YACC
AC_DECL_YYTEXT
AC_PROG_LEX
ALL_LINGUAS
AM_C_PROTOTYPES
AM_GNU_GETTEXT
AM_MAINTAINER_MODE
configure. Если используется данный макрос, то automake
отключит правило `maintainer-only' в сгенерированных файлах
`Makefile.in'. Этот макрос запрещен в режиме `Gnits' (see section Эффект --gnu и --gnits).
Этот макрос определяет условный оператор `MAINTAINER_MODE', который
вы можете использовать в ваших собственных файлах `Makefile.am'.
AC_SUBST
AC_CHECK_TOOL
AC_CHECK_PROG
AC_CHECK_PROGS
AC_PATH_PROG
AC_PATH_PROGS
Automake включает в себя некоторое количество макросов Autoconf, которые
могут быть использованы в вашем пакете; в некоторых ситуациях они
требуются для работы Automake. Эти макросы должны быть определены в
вашем файле `aclocal.m4'; иначе они не будут обнаружены программой
autoconf.
Программа aclocal автоматически создаст файл `aclocal.m4' на
основе содержимого `configure.in'. Это обеспечивает удобный способ
для получения макросов Automake, без выполнения дополнительного
поиска. Также механизм aclocal является расширяемым для
использования другими пакетами.
При запуске программа aclocal производит поиск макроопределений
во всех файлах `.m4', которые она может найти. Затем она сканирует
`configure.in'. Любое упоминание одного из найденных на первом
этапе макросов вызывает то, что этот макрос и любые другие макросы,
которые требуются для работы найденного макроса будут помещены в файл
`aclocal.m4'.
Если файл `acinclude.m4' существует, то его содержимое также будет автоматически включено в `aclocal.m4'. Это полезно для включения локальных макросов в `configure'.
Программа aclocal работает со следующими ключами командной строки:
--acdir=dir
--help
-I dir
--output=file
--print-ac-dir
aclocal будет производить поиск
файлов `.m4'. При задании этого ключа подавляется обычная обработка.
Этот ключ используется пакетом для определения места куда будет
производится установка файлов с макросами.
--verbose
--version
AM_CONFIG_HEADER
AM_ENABLE_MULTILIB
AM_FUNC_STRTOD
strtod не доступна, или работает неправильно (как в
SunOS 5.4), то строка `strtod.o' добавляется к выводимой переменной
LIBOBJS.
AM_FUNC_ERROR_AT_LINE
error_at_line не найдена, то строка `error.o'
добавляется к LIBOBJS.
AM_FUNC_MKTIME
mktime. Если функция не найдена, то
добавляется `mktime.o' к переменной `LIBOBJS'.
AM_FUNC_OBSTACK
AM_C_PROTOTYPES
AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
TIOCGWINSZ требует наличия файла
`<sys/ioctl.h>', то определите переменную GWINSZ_IN_SYS_IOCTL.
Иначе поиск TIOCGWINSZ будет осуществляться в `<termios.h>'.
AM_INIT_AUTOMAKE
AC_DEFINE макросы `PACKAGE' и
`VERSION'. Такого поведения можно избежать передавая непустой
третий аргумент.
AM_PATH_LISPDIR
emacs, и если она найдена, то устанаваливает
выходную переменную lispdir равной полному пути к каталогу site-lisp
программы Emacs.
AM_PROG_CC_STDC
CC чтобы заставить его
работать в этом режиме. Этот макрос пробует разные ключи командной строки
компилятора, которые выбирают режим ANSI C
на некоторых системах. Считается, что компилятор находится в режиме
ANSI C, если он корректно обрабатывает прототипы функций.
Если вы используете этот макрос, то вы должны проверить, что после его вызова
компилятор C будет работать в режиме ANSI C; если это не так, то переменная
среды am_cv_prog_cc_stdc устанаваливается в значение `no'. Если
вы написали свою программу в стандарте ANSI C, то вы можете создать ее копию в
не-ANSI стандарте, используя ключ ansi2knr (see section Автоматическая де-ANSI-фикация).
AM_PROG_LEX
AC_PROG_LEX с AC_DECL_YYTEXT (see section `Проверка отдельных программ' in Руководство Autoconf),
automake использует скрипт missing на системах, в которых нет
lex. Одной из таких систем является `HP-UX 10'.
AM_SANITY_CHECK
AM_INIT_AUTOMAKE.
AM_SYS_POSIX_TERMIOS
am_cv_sys_posix_termios устанавливается в
значение `yes'. Если происходит сбой, то значением переменной будет
являться `no'.
AM_TYPE_PTRDIFF_T
AM_WITH_DMALLOC
WITH_DMALLOC и добавлен ключ `-ldmalloc' в
переменную LIBS.
AM_WITH_REGEX
configure.
Если этот ключ указан (по умолчанию), то используется библиотека регулярных
выражений `regex', файл `regex.o' помещается в `LIBOBJS'
и определяется переменная `WITH_REGEX'. Если задан ключ `--without-regex',
то используется библиотека регулярных выражений `rx' и добавляется
`rx.o' в переменную `LIBOBJS'.
Программа aclocal не имеет никакого встроенного в нее знания о
макросах, так что ее легко расширить вашими собственными макросами.
Это свойство в основном используется для библиотек, которые хотят предоставить
собственные макросы Autoconf для использования другими
программами. Например, библиотека gettext предоставляет макрос
AM_GNU_GETTEXT, который должен быть использован любым пакетом,
использующим gettext. При установке библиотеки этот макрос
устанавливается туда, где aclocal сможет его найти.
Файл макросов должен быть серией вызовов AC_DEFUN. Программа
aclocal также понимает директиву AC_REQUIRE, так что
вполне безопасно помещать каждый из макросов в отдельный
файл. See section `Prerequisite Macros' in Руководство Autoconf, и
section `Макроопределения' in Руководство Autoconf.
Имя файла макросов должно оканчиваться на `.m4'. Такие файлы должны устанавливаться в каталог `$(datadir)/aclocal'.
В пакетах, не относящихся к типу flat, в файле `Makefile.am' верхнего
уровня надо указать Automake в каких подкаталогах будет производится сборка.
Это выполняется с помощью переменной SUBDIRS.
Макрос SUBDIRS содержит список подкаталогов, в которых может
производится сборка любого типа. Много целей (например all) в
сгенерированном файле `Makefile' будет запускаться и в текущем
каталоге, и во всех указанных подкаталогах. Заметьте, что подкаталоги,
перечисленные в SUBDIRS не обязаны содержать файл
`Makefile.am'; а только `Makefile' (после выполнения
настройки). Это позволяет использовать библиотеки из пакетов, которые не
используют Automake (таких как gettext). Каталоги, упомянутые в
SUBDIRS должны быть прямыми потомками текущего
каталога. Например, вы не можете поместить каталог `src/subdir' в
переменную SUBDIRS.
В пакете типа deep, `Makefile.am' верхнего уровня часто очень короток. Например, вот `Makefile.am' из дистрибутива GNU Hello:
EXTRA_DIST = BUGS ChangeLog.O README-alpha SUBDIRS = doc intl po src tests
Можно переопределить переменную SUBDIRS, если (как в случае
GNU Inetutils) вы хотите собрать только некоторую часть пакета.
Для этого включите в ваш файл `Makefile.am' следующие строки:
SUBDIRS = @SUBDIRS@
Затем в вашем файле `configure.in' вы можете указать:
SUBDIRS = "src doc lib po" AC_SUBST(SUBDIRS)
В результате этого, Automake сможет при построении пакета взять список
подкаталогов, но не будет связывать этот список, пока не будет запущен
configure.
Хотя макрос SUBDIRS может содержать подстановки (например
`@DIRS@'); сам Automake в действительности не проверяет
содержимое этой переменной.
Если определена переменная SUBDIRS, то ваш файл
`configure.in' должен включать макрос AC_PROG_MAKE_SET.
Использование SUBDIRS не ограничено только `Makefile.am'
верхнего уровня. Automake может быть использован для создания пакетов
любой глубины.
По умолчанию Automake создает файл `Makefiles', который работает
выполняя сначала make в подкаталогах. (`postfix'). Однако можно
изменить это поведение. Вы можете сделать это, поместив `.' в
переменную SUBDIRS. Например, поместив `.' в начало списка,
вы заставите выполнять make сначала в текущем каталоге, а затем уже в
подкаталогах.
Большая часть функциональности Automake направлена на то, чтобы сделать легким построение программ и библиотек.
В каталоге, содержащем исходные тексты, из которых будет построена
программа (как противоположность библиотеке), в основном используется
макрос `PROGRAMS'. Программы могут быть установлены в каталоги
bindir, sbindir, libexecdir, pkglibdir или
вообще не устанавливаться (`noinst').
Например:
bin_PROGRAMS = hello
В этом простом примере, результирующий `Makefile.in' будет
содержать код для генерации программы с именем hello. Переменная
hello_SOURCES используется для указания того, какие файлы
исходных текстов будут использованы для построения исполняемого файла:
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h
В результате этого каждый упомянутый в этой переменной файл `.c' будет скомпилирован в соответствующий файл `.o'. Затем, они все компонуются для создания `hello'.
Если переменная `prog_SOURCES' необходима, но не указана, то она получает значение по умолчанию равное единственному файлу `prog.c'.
В одном каталоге могут быть построены несколько программ. Много программ могут делить один и тот же исходный файл, который должен быть указан в каждом определении `_SOURCES'.
Заголовочные файлы перечисленные в определении `_SOURCES' включаются в дистрибутив, а в других случаях игнорируются. В том случае, если это не очень удобно, вы не должны включать файл, созданный `configure' в переменную `_SOURCES'; этот файл не должен распространяться. Файлы Lex (`.l') и Yacc (`.y') также должны быть перечислены; смотрите раздел section Поддержка Yacc и Lex.
Automake должен знать все файлы исходных текстов, которые вероятно
составят программу, даже если не все файлы будут построены в каждом
конкретном случае. Любые файлы, которые строятся только при выполнении
отдельных условий, должны быть перечислены в соответствующей переменной
`EXTRA_'. Например, если `hello-linux.c' будет в зависимости
от условий включен в программу hello, то файл `Makefile.am'
должен содержать:
EXTRA_hello_SOURCES = hello-linux.c
Иногда также полезно аналогичным образом определить во время
конфигурации какие программы будут построены. Например, GNU cpio
создает программы mt и rmt при выполнении определенных
условий.
В этом случае вы должны уведомить Automake обо всех программах, которые
могут быть построены, но в тоже время заставить сгенерированный файл
`Makefile.in' использовать программы, заданные при выполнении
configure. Это делается подстановкой значений при выполнении
configure в каждое из определений `_PROGRAMS'. А все
программы, которые можно создать перечисляются в переменной
EXTRA_PROGRAMS.
Если вы хотите скомпоновать программу с библиотеками, которые не найдены
configure, то для этого вы должны использовать переменную
LDADD. Эта переменная может быть использована для добавления
любых команд в командную строку компоновщика.
Иногда несколько программ создается в одном каталоге, но они не
разделяют одни и те же требования для компоновки. В этом случае для
переопределения глобальной переменной LDADD вы можете
использовать переменную `prog_LDADD' (где prog является
именем программы, как оно появляется в некоторых переменных
`_PROGRAMS', и обычно записывается буквами в нижнем регистре). Если
эта переменная существует для заданной программы, то про программа
компонуется без использования данных указанных в LDADD.
Например, в GNU cpio, pax, cpio и mt компонуются с
библиотекой `libcpio.a'. Однако, rmt, создаваемый в том же
каталоге, не имеет тех же требований к компоновке. Также программы
mt и rmt создаются только на определенных типах машин. Вот
как выглядит `src/Makefile.am' из поставки cpio (в сокращенном
виде):
bin_PROGRAMS = cpio pax @MT@ libexec_PROGRAMS = @RMT@ EXTRA_PROGRAMS = mt rmt LDADD = ../lib/libcpio.a @INTLLIBS@ rmt_LDADD = cpio_SOURCES = ... pax_SOURCES = ... mt_SOURCES = ... rmt_SOURCES = ...
`prog_LDADD' не подходит для передачи специфических для программы флагов компоновщика (за исключением `-l' и `-L'). Для передачи таких флагов используйте переменную `prog_LDFLAGS'.
Также иногда полезно собирать программу, в зависимости от цели, которая не является частью этой программы. Это может быть сделано используя переменную `prog_DEPENDENCIES'. Каждая программа зависит от содержимого такой переменной, но никакой дополнительной интерпретации не производится.
Если переменная `prog_DEPENDENCIES' не определена, то она будет вычислена Automake. Автоматически присвоенная величина с большинством подстановок configure является содержимым переменной `prog_LDADD'. Ключи `-l' и `-L' удаляются. Остающимися подстановками configure являются только `@LIBOBJS@' и `@ALLOCA@'; они остаются потому, что они не вызовут генерацию неправильных значений для `prog_DEPENDENCIES'.
Построение библиотеки в большинстве аналогично построению программы. В
этом случае, основой имени является `LIBRARIES'. Библиотеки могут
быть установлены в каталоги libdir или в pkglibdir.
Смотрите See section Построение разделяемой библиотеки, для информации о том, как построить разделяемые библиотеки используя программу Libtool и основу `LTLIBRARIES'.
Каждая переменная `_LIBRARIES' является списком библиотек, которые должны быть построены. Например, для того, чтобы создать библиотеку с именем `libcpio.a', но не устанавливать ее, вы должны написать:
noinst_LIBRARIES = libcpio.a
Файлы исходных текстов для библиотек определяются точно так же, как и для программ, через переменные `_SOURCES'. Заметьте, что имя библиотеки является канонизированным (see section Как именуются унаследованные переменные), так что переменная `_SOURCES' для `liblob.a' является равной `liblob_a_SOURCES', а не `liblob.a_SOURCES'.
Дополнительные объекты могут быть добавлены в библиотеку используя
переменную `library_LIBADD'. Это можно использовать для
объектов, определенных configure. Далее пример из cpio:
libcpio_a_LIBADD = @LIBOBJS@ @ALLOCA@
Automake явно распознает использование переменных @LIBOBJS@ и
@ALLOCA@, и использует эту информацию вместе со списком файлов
LIBOBJS полученом из `configure.in' для автоматического
включения соответствующих файлов исходных текстов в дистрибутив
(see section Что входит в дистрибутив). Эти файлы исходных текстов также обрабатываются для
автоматического определения зависимостей; смотрите раздел
See section Автоматическое отслеживание зависимостей.
Использование @LIBOBJS@ и @ALLOCA@ распознается в
любой переменной `_LDADD' или `_LIBADD'.
Построение разделяемой библиотеки является относительно сложной задачей. Для помощи в построении разделяемых библиотек, независимо от платформы, была создана программа GNU Libtool (see section `Введение' in Руководство Libtool).
Automake использует Libtool для построения библиотек, указанных в переменной `LTLIBRARIES'. Каждая переменная `_LTLIBRARIES' является списком разделяемых библиотек, которые нужно построить. Например, для создания библиотеки с именем `libgettext.a' и соответствующей ей разделяемой библиотеки, а также их установки в `libdir', вы должны написать:
lib_LTLIBRARIES = libgettext.la
Заметьте, что разделяемые библиотеки должны быть установлены, так
что использование check_LTLIBRARIES не разрешено. Однако
разрешено использование переменной noinst_LTLIBRARIES. Это
свойство должно быть использовано для "готовых библиотек" libtool.
Для каждой библиотеки, переменная `library_LIBADD' содержит имена дополнительных объектов libtool (файлы `.lo'), которые будет добавляться в разделяемую библиотеку. Переменная `library_LDFLAGS' содержит любые дополнительные флаги libtool, такие как `-version-info' или `-static'.
В то время как обычные библиотеки могут включать @LIBOBJS@,
библиотеки использующие libtool должны использовать
@LTLIBOBJS@. Это требуется, поскольку имена объектных файлов
над которыми работает libtool не обязательно оканчиваются на
`.o'. Руководство по libtool содержит более детальное описание этой
темы.
Для библиотек, устанавливаемых в некоторый каталог, Automake будет
автоматически снабжать их соответствующим ключом `-rpath'. Однако
для библиотек, определенных в время конфигурации (и таким образом
перечисленных в переменной EXTRA_LTLIBRARIES), Automake не знает
возможных каталогов установки; для таких библиотек вы должны сами
добавить ключ `-rpath' в соответствующую переменную
`_LDFLAGS'.
Для подробного описания смотрите See section `Руководство Libtool' in Руководство Libtool.
Иногда полезно знать какие переменные `Makefile' Automake использует для компиляции; например вам может быть необходима ваша собственная компиляция в некоторых случаях.
Некоторые переменные наследуются от Autoconf; это переменные CC,
CFLAGS, CPPFLAGS, DEFS, LDFLAGS, и
LIBS.
Также есть некоторые дополнительные переменные, определенные самим Automake:
INCLUDES
AC_CONFIG_HEADER или
AM_CONFIG_HEADER).
INCLUDES может быть использован для других ключей cpp, а
не только для `-I'. Например, эта переменная используется для
передачи специальных ключей `-D' вашему компилятору.
COMPILE
LINK
В Automake есть некоторая поддержка Yacc и Lex.
Automake предполагает, что файлы с расширением `.c', которые
создаются yacc (или lex) должны называться точно также как
и входной файл. Так что при использовании исходного файла yacc с именем
`foo.y', Automake будет считать, что промежуточный файл будет
называться `foo.c' (в противоположность имени `y.tab.c',
которое является более традиционным).
Расширение имени файла с исходным текстом yacc используется для определения расширения имени готового файла на языках `C' или `C++'. Файлы с расширением `.y' будут превращены в файлы с расширением `.c'; аналогично `.yy' станут `.cc'; `.y++' станут `c++'; и `.yxx' станут `.cxx'.
Подобным образом исходные тексты lex могут быть использованы для создания файлов на `C' или `C++'; распознаются файлы с расширениями `.l', `.ll', `.l++' и `.lxx'.
Вы не должны явно упоминать промежуточные файлы (на `C' или `C++') в любой из переменных `SOURCES'; вы должны указывать только список исходных файлов.
Промежуточные файлы созданные yacc (или lex) будут
включены в любой из созданных дистрибутивов. Таким образом пользователю
не обязательно иметь у себя yacc или lex сборки пакета.
Если был обнаружен исходный текст yacc, то ваш файл
`configure.in' должен определить переменную `YACC'. Это легко
делается макросом `AC_PROG_YACC' (see section `Проверка отдельных программ' in Руководство Autoconf).
Аналогичным образом, если есть исходный текст lex, то в
`configure.in' должна быть определена переменная `LEX'. Вы
можете использовать для этого макрос `AC_PROG_LEX'
(see section `Проверка отдельных программ' in Руководство Autoconf). Поддержка lex в Automake также требует
использования макроса `AC_DECL_YYTEXT'---automake необходимо знать
значение `LEX_OUTPUT_ROOT'. Все это отрабатывает при использовании
макроса AM_PROG_LEX (see section Макросы Autoconf, поставляемые с Automake).
Automake делает возможным включение в одну программу нескольких исходных
файлов yacc (или lex). Для запуска yacc (или
lex) в подкаталогах Automake использует небольшую программу,
называемую ylwrap. Это необходимо, поскольку имя выходное файла
yacc является фиксированным и параллельное выполнение make может
одновременно запустить несколько экземпляров yacc. Программа
ylwrap распространяется вместе с Automake. Она должна быть в
каталоге, указанном переменной `AC_CONFIG_AUX_DIR' (see section `Нахождение ввода `configure'' in Руководство Autoconf) или в
текущем каталоге, если данный макрос не используется в
`configure.in'.
Для yacc простая обработка блокировок является
неэффективной. Вывод yacc всегда использует внутри одни и те же
имена символов, так что невозможно скомпоновать два парсера yacc
в одну и ту же программу.
Мы рекомендуем использование следующего приема с переименованием
объектов, который используется в gdb:
#define yymaxdepth c_maxdepth #define yyparse c_parse #define yylex c_lex #define yyerror c_error #define yylval c_lval #define yychar c_char #define yydebug c_debug #define yypact c_pact #define yyr1 c_r1 #define yyr2 c_r2 #define yydef c_def #define yychk c_chk #define yypgo c_pgo #define yyact c_act #define yyexca c_exca #define yyerrflag c_errflag #define yynerrs c_nerrs #define yyps c_ps #define yypv c_pv #define yys c_s #define yy_yys c_yys #define yystate c_state #define yytmp c_tmp #define yyv c_v #define yy_yyv c_yyv #define yyval c_val #define yylloc c_lloc #define yyreds c_reds #define yytoks c_toks #define yylhs c_yylhs #define yylen c_yylen #define yydefred c_yydefred #define yydgoto c_yydgoto #define yysindex c_yysindex #define yyrindex c_yyrindex #define yygindex c_yygindex #define yytable c_yytable #define yycheck c_yycheck #define yyname c_yyname #define yyrule c_yyrule
Для каждого из определений замените префикс `c_' на то, что вы
хотите использовать. Эти определения работают для программ bison,
byacc и традиционных yacc. Если вы обнаружили, что тот
генератор парсеров, использующий эти символы не указан в этом списке, то
сообщите нам новое имя, чтобы мы добавили его в наш список.
Automake включает полную поддержку for C++.
Любой пакет, включающий код на C++ должен определить переменную
`CXX' в файле `configure.in'; самым простым способом сделать
это является использования макроса AC_PROG_CXX (see section `Проверка отдельных программ' in Руководство Autoconf).
Несколько дополнительных переменных определяются при обнаружении исходных файлов на C++:
CXX
CXXFLAGS
CXXCOMPILE
CXXLINK
Automake включает в себя полную поддержку Fortran 77.
Любой пакет, включающий исходные тексты на языке Fortran 77 должен
определить выходную переменную `F77' в файле `configure.in';
самым простым способом является использование макроса AC_PROG_F77
(see section `Проверка отдельных программ' in Руководство Autoconf). See section Fortran 77 и Autoconf.
Несколько отдельных переменных определяются при использовании исходных текстов Fortran 77:
F77
FFLAGS
RFLAGS
F77COMPILE
FLINK
Automake может выполнять предварительную обработку исходных файлов Fortran 77 и Ratfor, в добавление к их компиляции(1). Automake также содержит некоторую поддержку для создания программ и разделяемых библиотек, которые написаны на смеси Fortran 77 и других языков (see section Использование Fortran 77 с C и C++).
Это описывается в следующих разделах.
Файл `N.f' автоматически создается из файла `N.F' или `N.r'. Это правило запускает препроцессор для преобразования исходных текстов Fortran 77 или Ratfor с директивами препроцессора в строгий исходный текст Fortran 77. Вот точные команды, которые используются для этого:
$(F77) -F $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)
$(F77) -F $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)
`N.o' автоматически создается из `N.f', `N.F' или `N.r' запуском компилятора Fortran 77. Для компиляции используются следующий команды:
$(F77) -c $(AM_FFLAGS) $(FFLAGS)
$(F77) -c $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)
$(F77) -c $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)
В настоящее время Automake предоставляет ограниченную поддержку создания программ и разделяемых библиотек, которые являются смесью Fortran 77 и C и/или C++. Однако существует много других реализаций, относящихся к смешиванию кода на Fortran 77 с кодом на других языках, которые в настоящее время не обрабатываются Automake, но которые обрабатываются другими пакетами(2).
Automake может предоставить вам помощь двумя способами:
FLIBS макросом Autoconf AC_F77_LIBRARY_LDFLAGS,
который поставляется со свежими версиями Autoconf (Autoconf версии 2.13
и выше). See section `Характеристики компилятора Fortran 77' in Autoconf.
Если Automake определяет, что программа или разделяемая библиотека
(упомянутые в некоторых основах _PROGRAMS или
_LTLIBRARIES) содержит исходный код, который является смесью
Fortran 77 и C и/или C++, то он требует вызова макроса
AC_F77_LIBRARY_LDFLAGS в файле `configure.in', и чтобы в
соответствующей переменной _LDADD (для программ) или
_LIBADD (для разделяемых библиотек) появились ссылки либо на
$(FLIBS), либо на @FLIBS@. Человек ответственный за
написание `Makefile.am' должен убедиться, что переменные
$(FLIBS) или @FLIBS@ находятся в соответствующих
переменных _LDADD или _LIBADD.
Например, рассмотрим следующий `Makefile.am':
bin_PROGRAMS = foo foo_SOURCES = main.cc foo.f foo_LDADD = libfoo.la @FLIBS@ pkglib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = bar.f baz.c zardoz.cc libfoo_la_LIBADD = $(FLIBS)
В этом случае Automake будет требовать, чтобы макрос
AC_F77_LIBRARY_LDFLAGS был упомянут в `configure.in'. Также,
если переменная @FLIBS@ не была упомянута в переменной
foo_LDADD и libfoo_la_LIBADD, то Automake выдаст
предупреждение.
Следующая диаграмма показывает как Automake производит выбор соответствующего компоновщика.
Например, если используемый код на Fortran 77, C и C++ компонуется в
одну программу, то выбирается компоновщик C++. В этом случае, если
компоновщики C или Fortran 77 требуют какие-либо специальные библиотеки,
которые не подключаются компоновщиком C++, то они должны быть вручную
добавлены пользователем в переменные _LDADD или _LIBADD
файла `Makefile.am'.
\ Linker
source \
code \ C C++ Fortran
----------------- +---------+---------+---------+
| | | |
C | x | | |
| | | |
+---------+---------+---------+
| | | |
C++ | | x | |
| | | |
+---------+---------+---------+
| | | |
Fortran | | | x |
| | | |
+---------+---------+---------+
| | | |
C + C++ | | x | |
| | | |
+---------+---------+---------+
| | | |
C + Fortran | | | x |
| | | |
+---------+---------+---------+
| | | |
C++ + Fortran | | x | |
| | | |
+---------+---------+---------+
| | | |
C + C++ + Fortran | | x | |
| | | |
+---------+---------+---------+
Имеющаяся в Automake поддержка Fortran 77 требует наличия свежей версии Autoconf, которая включает в себя поддержку Fortran 77. Полная поддержка Fortran 77 была добавлена в Autoconf 2.13, так что вы можете использовать эту версию Autoconf или более позднюю.
В настоящее время Automake включает в себя полную поддержку только C, C++ (see section Поддержка C++) и Fortran 77 (see section Поддержка Fortran 77). Поддержка других языков находится в зачаточном состоянии и будет улучшена при требовании пользователей.
Хотя стандарты GNU позволяют использование ANSI C, это может привести к ограничению переносимости пакета на некоторые компиляторы (особенно SunOS).
Automake позволяет вам решить проблему с такими машинами путем де-ANSI-фикации каждого исходного файла до проведения компиляции.
Если в `Makefile.am' переменная AUTOMAKE_OPTIONS
(see section Изменение поведения Automake) содержит ключ ansi2knr, то в генерируемый
файл `Makefile.in' будет вставлен код для де-ANSI-фикации.
Это заставит считать каждый исходный текст на языке C считаться как
соответствующий ANSI C. Если доступен компилятор соответствующий ANSI C,
то он будет использован. если компилятор ANSI C не доступен, то для
преобразования исходных файлов в стандарт K&R будет использована
программа ansi2knr, а затем преобразованные файлы будут
скомпилированы.
Программа ansi2knr является бесхитростной. Она предполагает, что
исходный текст будет отформатирован определенным способом; для подробного
описания смотрите справочную страницу ansi2knr.
Поддержка де-ANSI-фикации требует наличия файлов `ansi2knr.c' и
`ansi2knr.1' в том же пакете, где находятся и исходные тексты на
ANSI C; эти файлы поставляются в комплекте Automake. Также файл
`configure.in' должен содержать вызов макроса
AM_C_PROTOTYPES (see section Макросы Autoconf, поставляемые с Automake).
Automake также работает в тех случаях, когда файлы ansi2knr
находятся в другом подкаталоге текущего пакета. Это делается добавлением
в опцию ansi2knr относительного пути к соответствующему
каталогу. Например, предположим, что исходные тексты на ANSI C
располагаются в подкаталогах `src' и `lib'. Файлы
`ansi2knr.c' и `ansi2knr.1' находятся в подкаталоге
`lib'. Вот что должно быть написано в `src/Makefile.am':
AUTOMAKE_OPTIONS = ../lib/ansi2knr
Если никакой префикс не задан, то считается, что файлы находятся в текущем каталоге.
Файлы перечисленные в переменной LIBOBJS и нуждающиеся в
де-ANSI-фикации не будут обрабатываться автоматически. Это происходит
из-за того, что configure будет генерировать имена объектных
файлов в виде `regex.o', в то время как make будет искать
`regex_.o' (при выполнении де-ANSI-фикации). В конечном счете эта
проблема может быть решена с помощью методов autoconf, но для
этого вы должны поместить следующий код в ваш файл `configure.in',
как раз перед вызовом макроса AC_OUTPUT:
# Это необходимо для того, чтобы файлы .o из переменной LIBOBJS также # обрабатывались с применением правил ANSI2KNR. LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
Очень часто для разработчика мучительным делом является постоянное обновление файла `Makefile.in' при изменении зависимостей включаемых в проект файлов. Automake предоставляет возможность автоматического отслеживания смены зависимостей и распространения зависимостей в сгенерированный `Makefile.in'.
В настоящее время эта поддержка требует использования GNU make и
gcc. В будущем может быть возможным поставка другой программы
генерации зависимостей, если это будет требоваться. По умолчанию этот
режим разрешен если в текущем каталоге определена любая программа или
библиотека на C, так что вы можете получить от не-GNU make ошибку
`Должен быть разделитель'.
Когда вы решаете создать дистрибутив, то цель dist перезапустит
automake с ключом `--include-deps' и другими
ключами. See section Создание файла `Makefile.in', и section Изменение поведения Automake. Это заставит вставить
предварительно сгенерированные зависимости в сгенерированный
`Makefile.in', и таким образом они окажутся в дистрибутиве. Этот
шаг также отключает включение в дистрибутив программы генерации
зависимостей, так что любой человек, загрузивший ваш дистрибутив и не
использующий GNU make и gcc, не получит ошибки.
При добавлении зависимостей в `Makefile.in', из них автоматически удаляются все специфические для данной системы зависимости. Это может быть сделано перечислением файлов в переменной `OMIT_DEPENDENCIES'. Например, Automake удаляет все ссылки на системные заголовочные файлы. Иногда полезно указать, чтобы были удалены отдельные заголовочные файлы. Например, если ваш файл `configure.in' использует макрос `AM_WITH_REGEX', то любая зависимость от файла `rx.h' или `regex.h' должны быть удалена, потому-что правильное значение не может быть известно до того, как пользователь выполнит конфигурацию пакета.
После того, как это сделано Automake достаточно умен для отработки отдельных случаев использования заголовочных файлов для регулярных выражений. Он также автоматически убирает зависимость от `libintl.h' при использовании `AM_GNU_GETTEXT'.
Автоматическое отлеживание зависимостей может быть запрещено помещением
no-dependencies в переменную AUTOMAKE_OPTIONS.
Если вы распаковываете дистрибутив, созданный make dist, и вы
хотите включить отслеживание зависимостей, то просто перезапустите
automake.
Файлы зависимостей помещаются в подкаталог с именем `.deps' каталога, где происходит построение. Эти зависимости являются специфическими для машины. Можно удалить их, если вы этого хотите; они будут автоматически созданы при следующей сборке.
Automake может обрабатывать унаследованные объекты, которые не являются программами на C. Иногда поддержка построения таких объектов должна быть предоставлена явно, но Automake все равно будет автоматически отрабатывать процесс установки и создания дистрибутива.
Также есть возможность опеределить и установить программы, которые являются скриптами. Эти программы перечисляются с использование основы имени `SCRIPTS'. Automake не определяет зависимости для скриптов; файл `Makefile.am' должен явно включать в себя соответствующие правила.
Automake не считает, что скрипты являются унаследованными объектами; такие скрипты должны удаляться вручную (see section Что будет очищено).
Сама программа automake является скриптом на Perl, так что она
генерируется на этапе конфигурации из `automake.in'. Вот как это
обрабатывается:
bin_SCRIPTS = automake
Поскольку automake появляется в макросе AC_OUTPUT, то для
нее цель создается автоматически:
Скрипты могут быть установлены в каталоги bindir, sbindir,
libexecdir или pkgdatadir.
Заголовочные файлы определяются семейством переменных `HEADERS'. В
общем заголовочные файлы не устанавливаются, так что в большинстве
случаев будет определена переменная noinst_HEADERS.
Все заголовочные файлы должны быть перечислены; отсутствующие файлы не будут включены в дистрибутив. Часто лучше всего перечислить неустановленные заголовочные файлы вместе с другими исходными текстами программы. See section Построение программ и библиотек. Заголовочные файлы перечисленные в переменных `_SOURCES' не надо указывать ни в одной из переменных `_HEADERS'.
Заголовочные файлы могут быть установлены в каталоги includedir,
oldincludedir или pkgincludedir.
Automake поддерживает установку различных файлов данных, используя семейство переменных `DATA'.
Такие данные могут быть установлены в каталоги datadir,
sysconfdir, sharedstatedir, localstatedir или
pkgdatadir.
По умолчанию файлы данных не включаются в дистрибутив.
Вот как Automake устанавливает свои вспомогательные файлы данных:
pkgdata_DATA = clean-kr.am clean.am ...
Время от времени находятся файлы, которые иначе должны называться
`source' (например файлы `.h' в С) в действительности
унаследованы из других файлов. Такие файлы должны быть перечислены в
переменной BUILT_SOURCES.
Построенные исходные тексты по умолчанию не компилируются. Для компиляции исходных текстов вы должны явно указать их в других переменных `_SOURCES'.
Заметьте, что в некоторые случаях, BUILT_SOURCES будет работать
каким-то странным образом. Для того, чтобы построение исходных текстов
работало с автоматическим отслеживанием зависимостей, файл
`Makefile' должен зависеть от $(BUILT_SOURCES). Это может
вызвать пересборку исходных текстов, что иногда может выглядеть забавно.
Поскольку Automake в основном предназначен для генерации файлов `Makefile.in' для использования в программах проекта GNU, то он старается взаимодействовать с другими утилитами GNU.
Automake предоставляет некоторую поддержку Emacs Lisp. Основная
переменная `LISP' используется для хранения списка файлов
`.el'. Возможными префиксами являются `lisp_' и
`noinst_'. Заметьте, что если определена переменная
lisp_LISP, то в `configure.in' должен использоваться макрос
AM_PATH_LISPDIR (see section Макросы Autoconf, поставляемые с Automake).
По умолчанию Automake будет производить байт-компиляцию всех исходных
текстов Emacs Lisp используя Emacs, который найден при выполнении
макроса AM_PATH_LISPDIR. Если вы не хотите производить
байт-компиляцию, то просто определите переменную ELCFILES с
пустым значением. Байт-скомпилированные файлы Emacs Lisp не переносимы
между разными версиями Emacs, так что отключите компиляцию, если
ожидаете, что сервера будут иметь несколько разных версий Emacs. К тому
же, много пакетов не извлекают пользу из байт-компиляции. Однако мы
рекомендуем вам оставить эту возможность разрешенной. Серверам с такими
странными установками лучше дать возможность справиться самим, чем
затруднять установку для остальных людей.
Если в файле `configure.in' есть макрос AM_GNU_GETTEXT, то
Automake включает поддержку GNU gettext, системы каталогов сообщений для
интернационализации (see section `GNU Gettext' in Утилиты GNU gettext).
Поддержка gettext в Automake требует добавления в пакет двух
подкаталогов, `intl' и `po'. Automake проверяет, что эти
подкаталоги существуют и упомянуты в переменной SUBDIRS.
Также Automake проверяет, что определение переменной ALL_LINGUAS
в файле `configure.in' соответствует всем файлам `.po', и
ничего более.
Automake обеспечивает некоторую автоматическую поддержку написания
модулей Guile. Automake включит поддержку Guile, если в
`configure.in' используется макрос AM_INIT_GUILE_MODULE.
В настоящее время поддержка Guile означает, что при выполнении макроса
AM_INIT_GUILE_MODULE будет:
AM_INIT_AUTOMAKE.
AC_CONFIG_AUX_DIR, который является частью
`..'.
Вследствие зрелости кода модулей Guile, нет никаких сомнений, что поддержка Automake будет развиваться.
Automake предоставляет поддержку GNU Libtool (see section `Introduction' in The Libtool Manual) с основной переменной `LTLIBRARIES'. See section Построение разделяемой библиотеки.
Automake предоставляет минимальную поддержку компиляции файлов Java, используя основную переменную `JAVA'.
Любые файлы `.java' перечисленные в переменной `_JAVA', будут
построены с помощью JAVAC. По умолчанию, файлы с расширением
`.class' не включаются в дистрибутив.
В настоящее время Automake принуждает к тому, чтобы в заданном `Makefile.am' может быть использована только одна переменная `_JAVA'. Причиной этого ограничения является то, что невозможно узнать какие файлы `.class' будет сгенерирован из файлов `.java'---так, что может быть невозможным узнать какие файлы необходимо устанавливать.
В настоящее время Automake обеспечивает поддержку Texinfo и справочных страниц.
Если текущий каталог содержит исходный текст Texinfo, то вы должны
указать это с помощью основы `TEXINFOS'. В общем случае файлы
Texinfo могут быть преобразованы в формат info, и поэтому макрос
info_TEXINFOS является наиболее часто используемым. Заметьте, что
имена файлов исходных текстов Texinfo должны заканчиваться на
`.texi' или `.texinfo'.
Если файл `.texi' включает в себя файл `version.texi', то он
должен быть сгенерирован автоматически. Файл `version.texi'
определяет три макроса Texinfo, на которые вы можете ссылаться:
EDITION, VERSION и UPDATED. Первые два макроса
содержат номер версии вашего пакета (но для ясности они разделены на две
части); последний макрос содержит дату изменения основного
файла. Поддержка `version.texi' требует наличия программы
mdate-sh; эта программа поставляется с Automake и автоматически
включается при запуске automake с ключом --add-missing.
Иногда файл info зависит от более чем одного файла
`.texi'. Например, в пакете GNU Hello, файл `hello.texi'
включает файл `gpl.texi'. Вы можете сообщить об этих зависимостях
Automake, используя переменную texi_TEXINFOS. Вот как это
делается в GNU Hello:
info_TEXINFOS = hello.texi hello_TEXINFOS = gpl.texi
По умолчанию Automake требует наличия файла `texinfo.tex' в том же
каталоге, что и исходные файлы Texinfo. Однако, если вы используете в
файле `configure.in' макрос AC_CONFIG_AUX_DIR (see section `Finding `configure' Input' in The Autoconf Manual), то
`texinfo.tex' ищется в заданном каталоге. Automake устанавливает
файл `texinfo.tex', если задан ключ `--add-missing'.
Если в вашем пакете файлы Texinfo находятся в нескольких каталогах, то
вы можете использовать переменную TEXINFO_TEX для того, чтобы
сообщить Automake о том, где найти файл `texinfo.tex'. Значением
этой переменной должен быть относительный путь от текущего файла
`Makefile.am' к файлу `texinfo.tex':
TEXINFO_TEX = ../doc/texinfo.tex
Ключ `no-texinfo.tex' может быть использован для отмены требования
наличия файла `texinfo.tex'. Однако предпочтительней использование
переменной TEXINFO_TEX, поскольку это позволяет работать цели
dvi.
Automake создает цель install-info; вероятно некоторые люди
используют ее. По умолчанию, страницы info устанавливаются при
выполнении `make install'. Это поведение может быть изменено
используя ключ no-installinfo.
Пакет также может включать в свой состав справочные страницы (но
посмотрите стандарты GNU для информации о них, section `Man Pages' in The GNU Coding Standards). Справочные страницы объявляются
используя основу `MANS'. В общем используется макрос
man_MANS. Справочные страницы автоматически устанавливаются в
зависимости от расширения файлов в соответствующие подкаталоги
mandir. Они не включаются в состав дистрибутива автоматически.
По умолчанию справочные страницы устанавливаются при выполнении
`make install'. Однако, поскольку проекты GNU не требуют наличия
справочных страниц, то много людей сопровождающих пакеты не расходуют
время на содержание справочных страниц в обновленном состоянии. В этих
случаях опция no-installman отключит установку справочных страниц
по умолчанию. Пользователь все равно будет иметь возможность явно
установить справочные страницы используя команду `make
install-man'.
Вот как документация обрабатывается в пакете GNU cpio (который
включает в себя и документацию в Texinfo и справочные страницы):
info_TEXINFOS = cpio.texi man_MANS = cpio.1 mt.1 EXTRA_DIST = $(man_MANS)
Исходные тексты Texinfo и страницы info считаются исходными файлами и включаются в состав дистрибутива.
В настоящее время справочные страницы не рассматриваются как исходные файлы, поскольку они не создаются автоматически. Поэтому они не включаются в состав дистрибутива автоматически.
Automake отрабатывает детали установки вашей программы после того как
она будет построена. Всё перечисленное в PROGRAMS,
SCRIPTS, LIBRARIES, LISP, DATA и
HEADERS автоматически устанавливается в соответствующие места.
Automake также обрабатывает установку указанных страниц info и справочных страниц.
В том случае когда программа установки устанавливает пакет на несколько
машин, с разделяемой структурой каталогов, Automake создает отдельные
цели install-data и install-exec---эти цели позволяют
установить машино-независимые части только один раз. Цель install
зависит от обоих этих целей.
Automake также создает цель uninstall, цель installdirs и
цель install-strip.
Также можно расширить этот механизм определением цели
install-exec-local или install-data-local. Если эти цели
определены, то они будут запущены при выполнении `make install'.
Переменные, использующие стандартные префиксы каталогов `data', `info', `man', `include', `oldinclude', `pkgdata' или `pkginclude' (например, `data_DATA') будут устанавливаться при выполнении цели `install-data'.
Переменные, использующие стандартные префиксы каталогов `bin', `sbin', `libexec', `sysconf', `localstate', `lib' или `pkglib' (e.g. `bin_PROGRAMS') устанавливаются целью `install-exec'.
Любые переменные, использующие определенные пользователем префиксы каталогов со словом `exec' в имени (например, `myexecbin_PROGRAMS' устанавливаются целью `install-exec'. Все другие определенные пользователем префиксы устанавливаются целью `install-data'.
Automake генерирует поддержку переменной `DESTDIR' во всех правилах установки. Переменная `DESTDIR' используется в процессе выполнения `make install' для перемещения устанавливаемых объектов в область установки. К каждому объекту и пути добавляется значение переменной `DESTDIR' до того, как быть скопированным в область установки. Вот пример типичного использования DESTDIR:
make DESTDIR=/tmp/staging install
Это помещает устанавливаемые объекты в дерево каталогов, которое создано в каталоге `/tmp/staging'. Если устанавливаются файлы `/gnu/bin/foo' и `/gnu/share/aclocal/foo.m4', то вышеприведенная команда установит `/tmp/staging/gnu/bin/foo' и `/tmp/staging/gnu/share/aclocal/foo.m4'.
Это свойство часто используется для построения пакетов и установок. Для получения дополнительной информации смотрите section `Makefile Conventions' in The GNU Coding Standards.
Стандарты GNU Makefile определяют несколько правил очистки.
В общем информация о том, какие файлы могут быть удалены может быть
автоматически определена Automake. Конечно, Automake также распознает
некоторые переменные, определенные для указания дополнительных файлов,
которые должны быть удалены. Этими переменными являются
MOSTLYCLEANFILES, CLEANFILES, DISTCLEANFILES и
MAINTAINERCLEANFILES.
Цель dist создаваемая в генерируемом файле `Makefile.in'
может быть использована для создания сжатого файла tar с
дистрибутивом. Имя tar-файла основывается на переменных `PACKAGE' и
`VERSION'; а точнее, он называется
`package-version.tar.gz'.
Вы можете использовать переменную make с именем `GZIP_ENV'
для того, чтобы управлять запуском gzip. Значением по умолчанию является
строка `--best'.
В большинстве случаев файлы, необходимые для дистрибутива автоматически
находятся Automake: все файлы исходных текстов автоматически включаются
в состав дистрибутива, также как и все файлы `Makefile.am' и
`Makefile.in'. Automake также имеет встроенный список часто
используемых файлов, которые если существуют в текущем каталоге, то
автоматически включаются в состав дистрибутива. Этот список показывается
при выполнении `automake --help'. Также автоматически включаются
файлы, которые читаются configure (например, файлы исходных
текстов, относящиеся к файлам, указанным при запуске макроса
AC_OUTPUT).
Все равно, иногда существуют файлы, которые должны входить в состав
дистрибутива, но которые не попадают в список файлов, созданный
автоматически. Эти файлы должны быть перечислены в переменной
EXTRA_DIST. Вы можете указывать в переменной EXTRA_DIST
файлы из подкаталогов. Вы можете также в ней указывать каталоги; в этом
случае весь каталог будет рекурсивно скопирован в дистрибутив.
Если вы определили переменную SUBDIRS, то Automake будет
рекурсивно включать подкаталоги в состав дистрибутива. Если
SUBDIRS определен условно (see section Условные операторы), то
Automake включит в дистрибутив все подкаталоги, которые могут появиться
в SUBDIRS. Если вам необходимо указать список каталогов условно,
то вы можете задать в переменной DIST_SUBDIRS точный список
подкаталогов, которые необходимо включить в дистрибутив.
Время от времени полезно иметь возможность изменить дистрибутив, до
того, как он будет создан. Если существует цель dist-hook, то она
запускается после создания каталога с дистрибутивом, но до того как
будет файл создан tar (или shar). Это применяется для распространения
файлов в подкаталоги, для которых новый файл `Makefile.am' является
избыточным:
dist-hook:
mkdir $(distdir)/random
cp -p $(srcdir)/random/a1 $(srcdir)/random/a2 $(distdir)/random
Automake также создает цель distcheck, которая может помочь
убедиться в том, что дистрибутив работает. distcheck создает
дистрибутив и пытается его построить VPATH.
Automake поддерживает две формы комплектов тестов.
Если определена переменная TESTS, то ее значение является списком
программ, которые надо запустить для проведения тестирования. Программы
могут быть либо унаследованными объектами, либо исходными объектами;
сгенерированное правило будет искать их и в srcdir, и в
`.'. Программы, которые нуждаются в файлах данных должны искать их
в каталоге srcdir (который указан в одноименных переменных среды
и make), так что они будут работать при построении в отдельном каталоге
(see section `Build Directories' in The Autoconf Manual), и в частности для цели distcheck (see section Что входит в дистрибутив).
Количество сбоев будет напечатано в конце запуска. Если заданная тестовая программа заканчивает работу с кодом 77, то ее результаты игнорируется в завершающем подсчете. Это свойство позволяет игнорировать непереносимые тесты, в тех случаях когда они не имеют значения.
Переменная TESTS_ENVIRONMENT может быть использована для
установки переменных среды для запускаемых тестов; при выполнении этого
правила переменная среды srcdir устанавливается. Если все ваши
тестовые программы являются скриптами, то вы также можете установить
переменную TESTS_ENVIRONMENT для вызова командного процессора
(например, `$(SHELL) -x'); это свойство может быть полезно при
отладке тестов.
Если в переменной AUTOMAKE_OPTIONS указано
`dejagnu',
то предполагается использования комплекта тестов на базе
dejagnu. Значение переменной DEJATOOL передается как
аргумент ключа --tool программы runtest; по умолчанию это
имя пакета.
Переменная RUNTESTDEFAULTFLAGS содержит флаги для ключей
--tool и --srcdir, которые по умолчанию передаются
dejagnu; в случае необходимости это поведение может быть изменено.
Переменные EXPECT, RUNTEST и RUNTESTFLAGS могут
быть переопределены для подстановки специфичных для проекта
значений. Например, если вам необходимо сделать это для тестирования ???
toolchain компилятора, поскольку значения по умолчанию не берут во
внимание имена машины и цели.
В других случаях тестирование производится через цель `make check'.
Различные возможности Automake могут контролироваться ключами в файле
`Makefile.am'. Такие ключи перечислены в специальной переменной с
именем AUTOMAKE_OPTIONS. В настоящее время распознаются следующие
ключи:
gnits
gnu
foreign
cygnus
gnits
также предполагает наличие ключей readme-alpha и
check-news.
ansi2knr
path/ansi2knr
check-news
make dist до тех пор, пока номер текущей версии не
появится в нескольких первых строках файла `NEWS'.
dejagnu
dejagnu правила.
See section Поддержка комплектов тестов.
dist-shar
dist-shar также как и обычную цель dist. Эта
новая цель будет создавать shar-архив дистрибутива.
dist-zip
dist-zip также как и обычную цель dist
Эта новая цель будет создавать zip-архив дистрибутива.
dist-tarZ
dist-tarZ также как и обычную цель dist
target. Эта новая цель будет создавать сжатый tar-архив дистрибутива;
предполагается использование традиционных программ tar и
compress. Предупреждение: Если вы в действительности используете
GNU tar, то созданный архив может содержать непереносимые
конструкции.
no-dependencies
no-installinfo
info и
install-info все равно будут доступны. Этот ключ запрещен при
уровне ограничения `GNU' и выше.
no-installman
install-man все равно будет
доступна для использования. Этот ключ запрещен при уровне ограничения
`GNU' и выше.
no-texinfo.tex
readme-alpha
Нераспознанные ключи оцениваются automake.
Существует несколько правил, которые нельзя отнести к вышеперечисленным пунктам.
etagsAutomake при некоторых обстоятельствах будет генерировать правила для генерации файлов `TAGS', которые используются с GNU Emacs.
Если присутствует любой исходный код на C, C++ или Fortran 77, то для
каталога будут созданы цели tags и TAGS.
В каталоге верхнего уровня пакета, состоящего из нескольких каталогов
цель tags создаст файл, при выполнении которой будет создавать
файл `TAGS', включающий все файлы `TAGS' из подкаталогов.
Также, если определена переменная ETAGS_ARGS, то будет
сгенерирована цель tags. Эта переменная предназначена для
каталогов, которые содержат исходные файлы, тип которых не понимает
etags, но которые можно обработать.
Вот как Automake создает таги для своих исходных файлов, а также для узлов файла Texinfo:
ETAGS_ARGS = automake.in --lang=none \ --regex='/^@node[ \t]+\([^,]+\)/\1/' automake.texi
Если вы добавили имена файлов к переменной `ETAGS_ARGS', то вы
вероятно захотите установить переменную
`TAGS_DEPENDENCIES'. Содержимое этой переменной будет полностью
добавлено к зависимости для цели tags.
Automake также сгенерирует цель ID, которая будет запускать
программу mkid на исходных файлах. Это поддерживается при
использовании покаталожной основы.
Иногда полезно ввести новое неявное правило для обработки новых типов
файлов, о которых Automake ничего не знает. Если вы сделали это, то вы
должны уведомить GNU Make о новых суффиксах. Это может быть сделано
помещением списка новых суффиксов в переменную SUFFIXES.
Например, в настоящее время Automake не обеспечивает никакой поддержки Java. Если вы напишите макрос для генерации файлов `.class' из файлов с исходными текстами `.java', то вы также должны добавить эти суффиксы в список.
SUFFIXES = .java .class
Для включения других файлов (может быть для подключения общих правил) поддерживается следующий синтаксис:
include ($(srcdir)|$(top_srcdir))/filename
Используя файлы в текущем каталоге:
include $(srcdir)/Makefile.extra
include Makefile.generated
Используя файлы в каталоге верхнего уровня:
include $(top_srcdir)/filename
Automake поддерживает простой тип условных операторов.
До использования условного оператора, вы должны определить его в файле
configure.in используя макрос AM_CONDITIONAL
(see section Макросы Autoconf, поставляемые с Automake). Макросу AM_CONDITIONAL передается два
аргумента.
Первым аргументом для AM_CONDITIONAL является имя условного
оператора. Им должны быть простая строка, начинающаяся с буквы и
содержащая только буквы, цифры и знаки подчеркивания.
Вторым аргументом AM_CONDITIONAL является условие для командного
процессора, которое можно использовать в операторе if. Условие
оценивается при запуске configure.
Условные операторы обычно зависят от ключей, которые использует
пользователь при запуске скрипта configure. Вот пример того, как
написать условный оператор, который возвращает истинное выражение, если
пользователь использовал ключ `--enable-debug'.
AC_ARG_ENABLE(debug,
[ --enable-debug Turn on debugging],
[case "${enableval}" in
yes) debug=true ;;
no) debug=false ;;
*) AC_MSG_ERROR(bad value ${enableval} for --enable-debug) ;;
esac],[debug=false])
AM_CONDITIONAL(DEBUG, test x$debug = xtrue)
Вот пример использования этого условного оператора в файле `Makefile.am':
if DEBUG DBG = debug else DBG = endif noinst_PROGRAMS = $(DBG)
Этот тривиальный пример также мог быть создан используя макрос EXTRA_PROGRAMS (see section Построение программ).
В операторе if вы можете тестировать только одну
переменную. Оператор else может не использоваться. Условные
операторы могут быть вложены на любую глубину.
Заметьте, что условные операторы в Automake не похожи на условные
операторы в GNU Make. Условные операторы Automake проверяются во время
конфигурации, при выполнении скрипта `configure', и воздействуют на
преобразование файла `Makefile.in' в файл `Makefile'. Они
основываются на ключах, передаваемых скрипту `configure' и на
результатах, определяемых во время выполнения `configure'. Условные
операторы GNU Make проверяются при выполнении make и основываются
на переменных, передаваемых программе make, или определенных в
`Makefile'.
Условные операторы Automake будут работать с любой программой make.
--gnu и --gnits
Ключ `--gnu' (или `gnu' в переменной `AUTOMAKE_OPTIONS')
заставляет automake выполнить проверку следующих вещей:
Заметьте, что в будущем этот ключ будет расширен для проведения
дополнительных проверок; рекомендуется ознакомиться с точными
требованиями стандартов GNU. Также ключ `--gnu' может требовать
наличия нестандартных программ GNU для использования в целях,
используемых человеком, который сопровождает данные пакет; например, в
будущем может потребоваться программа pathchk для работы цели
`make dist'.
Ключ `--gnits' делает то же самое, что и ключ `--gnu', а также проверяет следующие вещи:
--cygnus
Cygnus Solutions применяет немного другие правила о том как будет
конструироваться файл `Makefile.in'. Передача ключа `--cygnus'
для automake вызовет то, что сгенерированный `Makefile.in'
будет соответствовать правилам Cygnus.
Вот точное описания действия ключа `--cygnus':
runtest, expect,
makeinfo и texi2dvi.
--foreign.
check не зависит от цели all.
Люди, сопровождающие программы GNU рекомендуют использовать уровень ограничений `gnu', а не режим Cygnus.
Неявная семантика копирования Automake означает, что много проблем может
быть решено простым добавлением некоторых целей для make и правил
для `Makefile.in'. Automake будет игнорировать эти добавления.
Есть некоторые предостережения для этих работ. Хотя вы можете переопределить цели, уже используемые Automake, но часто это просто неразумно, особенно в каталоге верхнего уровня пакета не относящегося к типу flat. Однако, вы можете указать в вашем файле `Makefile.in' различные полезные цели, имеющие суффикс `-local'. Automake дополнит стандартные цели этими целями пользователя.
К целям, поддерживающим локальную версию относятся: all,
info, dvi, check, install-data,
install-exec, uninstall и разные цели clean
(mostlyclean, clean, distclean и
maintainer-clean). Заметьте, что в этом списке нет целей
uninstall-exec-local или uninstall-data-local; есть только
uninstall-local. Это не имеет значения для удаления только данных
или исполняемых файлов.
Например, вот один из способов установить файл в каталог `/etc':
install-data-local:
$(INSTALL_DATA) $(srcdir)/afile /etc/afile
Некоторые цели также имеют способ запускать другие цели после выполнения
всех своих действий, это называется ловушка (hook). Ловушка
называется по имени цели, с добавлением суффикса `-hook'. Целями,
разрешающими использование ловушек являются install-data,
install-exec, dist и distcheck.
Например, вот как создать жесткую ссылку на установленную программу:
install-exec-hook:
ln $(bindir)/program $(bindir)/proglink
Automake не помещает никаких ограничения на распространение готовых файлов `Makefile.in'. Мы все еще поощряем авторов к распространению их работ под действием правил подобных GPL, но не требуем использование Automake.
Некоторые из файлов, которые могут быть автоматически установлены при
использовании ключа командной строки --add-missing могут вызвать
ошибку при использовании GPL; просмотрите каждый файл для получения
информации.
Вот некоторые вещи, которые могут появиться в будущем:
Jump to: # - - - @ - _ - a - b - c - d - e - f - g - h - i - l - m - n - o - p - r - s - t - u - v - y - ц - д - к - о - п - с - А - Ц - Д - Е - Ф - И - К - М - Н - О - П - Р - С - Т - У - З
Jump to: # - - - @ - _ - a - b - c - d - e - f - g - h - i - l - m - n - o - p - r - s - t - u - v - y - ц - д - к - о - п - с - А - Ц - Д - Е - Ф - И - К - М - Н - О - П - Р - С - Т - У - З
This document was generated on 31 March 2000 using texi2html 1.56k.