@dircategory GNU admin * automake: (automake.ru). Использование Automake. Создание Makefile.in
@dircategory Отдельные утилиты * aclocal: (automake.ru) Использование 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 `Введение' in Руководство Autoconf), а также налагает некоторые ограничения на содержимое файла `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' без изменений. Это позволяет вам добавлять в генерируемый
файл `Makefile.in' произвольный код. Например, дистрибутив Automake
включает в себя нестандартную цель cvs-dist, которую использует
человек, сопровождающий Automake, для создания дистрибутивов из системы контроля
исходного кода.
Заметьте, что расширения GNU make не распознаются программой Automake. Использование таких расширений в файле `Makefile.am' приведет к ошибкам или странному поведению.
Automake пытается сгруппировать комментарии к расположенным по соседству xцелям и макроопределениям.
Цель, определенная в `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 поддерживает три типа иерархии каталогов: плоскую,
неглубокую и глубокую.
Если все файлы пакета располагаются в одном каталоге, то это плоский
пакет. В файле `Makefile.am' для этого типа пакета по определению
отсутствует макрос SUBDIRS. Примером такого пакета может служить
termutils.
Глубокий пакет -- это такой, в котором все исходные тексты лежат
в подкаталогах; каталог верхнего уровня содержит в основном конфигурационную
информацию. Хорошим примером такого пакета является GNU cpio,
а так же GNU tar. Файл `Makefile.am' в каталоге верхнего
уровня глубокого пакета содержит макрос SUBDIRS, но в нем нет
никаких других макросов для определения объектов компиляции.
Неглубокий пакет подразумевает, что основные файлы исходных
текстов располагаются в каталоге верхнего уровня, а различные части этого
пакета (обычно библиотеки) находятся в подкаталогах. К пакетам такого типа
относится Automake (а также GNU make, который в настоящее время
не использует automake).
Хотя Automake предназначен для использования людьми, сопровождающими пакеты GNU, он также старается приспособиться и к тем, кто хочет использовать Automake, но не хочет соблюдать все соглашения GNU.
Сейчас Automake поддерживает три уровня строгости (strictness), задающих, сколь строго Automake должен проверять соответствие стандартам.
Строгость может принимать следующие значения:
Для более детальной информации о точном смысле уровня строгости смотрите
section Эффект использования ключей --gnu
и --gnits.
Макросы Automake (с этого места мы будем ссылаться на них как на переменные)
в общем следуют Единообразной Схеме Именования, которая позволяет
легко понять, как собираются программы (и другие результирующие объекты),
и как они устанавливаются. Эта схема также поддерживает определение того,
что должно быть собрано во время выполнения configure.
Во время выполнения make, некоторые переменные используются
для определения того, что должно быть собрано. Эти переменные называются
основными переменными. Например, основная переменная PROGRAMS
содержит список программ, которые должны быть скомпилированы и собраны.
Различные наборы переменных используются для принятия решения о том,
куда должны быть установлены собранные объекты. Эти переменные называются
подобно основным переменным, но имеют префикс, указывающий, какой из стандартных
каталогов должен быть использован в качестве каталогаx для установки. Имена
стандартных каталогов определены в стандартах GNU (see section `Directory
Variables' in The GNU Coding Standards). Automake расширяет
это список переменными pkglibdir, pkgincludedir
и pkgdatadir, которые имеют те же значения, что и не-`pkg'
версии, но с прибавленным к ним суффиксом `@PACKAGE@'. Например,
pkglibdir определена как $(datadir)/@PACKAGE@.
Для каждой из основных переменных также существует дополнительная переменная,
имя которой образовано добавлением префикса `EXTRA_' к имени
основной переменной. Эта переменная используется для перечисления объектов,
которые могут быть собраны, а могут и не собраны в зависимости от принятого
configure решения. Для того, чтобы создать файл `Makefile.in',
работающий в любой ситуации, Automake должен сразу узнать полный список объектов,
которые вообще могут быть собраны. Исходя из этого, переменные с префиксом
`EXTRA_' обязательны.
Например, пакет 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
--- программу, от которой у всех кружится голова. Вы использовали Autoconf
для обеспечения переносимости, но ваш файл `Makefile.in' был написан
бессистемно. Вы же хотите сделать его пуленепробиваемым, и поэтому решаете
использовать 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 является глубоким пакетом.
Вот файл `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 если пакет не является
плоским. See section `Создание файлов вывода' in Руководство Autoconf.
AM_SANITY_CHECK для того, чтобы убедиться,
что среда, в которой будет производится сборка пакета, является нормальной.
AC_PROG_INSTALL (see section `Проверка
отдельных программ' 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-ru, $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 make. Остальные файлы интерпретируются по разному.
В настоящее время отличие состоит лишь в том, что файлы `Makefile'
удаляются make distclean, тогда как другие файлы удаляются командой
make clean. Также Automake распознает использование некоторых макросов и в соответствии с ними генерирует `Makefile.in'. Вот список распознаваемых макросов и результатов их работы:
AC_CONFIG_HEADER AM_CONFIG_HEADER,
который похож на AC_CONFIG_HEADER (see section `Заголовочные
файлы настройки' in Руководство Autoconf), но кроме этого выполняет
полезную работу, специфичную для 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, но кроме
этого он определяет в файле `Makefile' переменные `build_alias'
и `target_alias'. 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. Если
таковая не найдена, то к переменной `LIBOBJS' добавляется `mktime.o'.
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),
но использует скрипт 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
`Hеобходимые макросы' in Руководство Autoconf, и section `Макроопределения'
in Руководство Autoconf.
Имя файла макросов должно оканчиваться на `.m4'. Такие файлы должны устанавливаться в каталог `$(datadir)/aclocal'.
В неплоских пакетах в файле `Makefile.am' верхнего уровня надо
указать Automake, в каких подкаталогах будет производится сборка. Это выполняется
с помощью переменной SUBDIRS.
Макрос SUBDIRS содержит список подкаталогов, в которых могут
производиться различные виды сборки. Многие цели (например, all)
в сгенерированном файле `Makefile' будут выполняться как в текущем
каталоге, так и во всех указанных подкаталогах. Заметьте, что подкаталоги,
перечисленные в SUBDIRS, не обязаны содержать файл `Makefile.am',
а только лишь `Makefile' (после выполнения конфигурации). Это позволяет
использовать библиотеки из пакетов, которые не используют Automake (например,
gettext). Каталоги, упомянутые в SUBDIRS, должны
быть прямыми потомками текущего каталога. Например, вы не можете поместить
каталог `src/subdir' в переменную SUBDIRS.
В глубоких пакетах `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 создает файлы `Makefile', которые работают,
выполняя сначала make в подкаталогах (постфиксный метод). Однако,
можно изменить это поведение, поместив `.' в переменную 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. Автоматически присвоенная ей величина является содержимым переменной `prog_LDADD' с большинством подстановок configure. Ключи `-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 `Introduction' in Libtool Manual).
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'.
Для подробного описания смотрите @xref{Использование Automake, Использование Automake с Libtool, libtool, Libtool Manual}.
Иногда полезно знать, какие переменные `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
Для каждого `#define' замените префикс `c_'
на то, что вы хотите использовать. Эти определения работают для программ
bison, byacc и традиционных yacc.
Если вы обнаружили, что какой-нибудь генератор парсеров использует символы,
не указанные в этом списке, то сообщите нам новое имя, чтобы мы добавили
его.
Automake полностью поддерживает 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, то он будет использован.
В противном случае для преобразования исходных файлов в стандарт 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:
# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
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 ...
Время от времени файлы, которые могли бы быть названы исходными
(например, файлы `.h' в C), в действительности порождаются из
других файлов. Такие файлы должны быть перечислены в переменной 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' включает в себя с помощью `@include'
файл `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 `Hахождение ввода `configure'' in Руководство Autoconf),
то `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' (например, `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 `Каталоги сборки'
in Руководство Autoconf), и в частности для цели 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 - j - l - m - n - o - p - r - s - t - u - v - y - б - ц - д - к - м - о - п - р - с - т - з - А - Ц - Д - Е - Ф - Г - И - К - М - Н - О - П - Р - С - Т - У - З
AC_OUTPUT, сканирование
AM_INIT_AUTOMAKE, пример
использования bin_PROGRAMS
PROGRAMS, bindir SUBDIRS, объяснение
SUBDIRS, переопределение
zardoz SUBDIRS
Jump to: # - - - . - @ - _ - a - b - c - d - e - f - g - h - i - j - l - m - n - o - p - r - s - t - u - v - y - б - ц - д - к - м - о - п - р - с - т - з - А - Ц - Д - Е - Ф - Г - И - К - М - Н - О - П - Р - С - Т - У - З
AC_OUTPUT, сканирование
AM_INIT_AUTOMAKE, пример
использования bin_PROGRAMS
PROGRAMS, bindir SUBDIRS, объяснение
SUBDIRS, переопределение
zardoz SUBDIRS
This document was generated on 2 April 2002 using texi2html 1.56k.