построение программ и библиотек

большая часть функциональности 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@

специальная обработка переменных `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

задает список ключей `-i'. может быть установлен в вашем файле `makefile.am', если у вас есть специальные каталоги, в которых вы хотите осуществлять поиск. automake автоматически подставляет некоторые ключи `-i'. в частности, он генерирует строку с ключами `-i$(srcdir)' и `-i', указывающий на каталог с файлом `config.h' (если вы используете ac_config_header или am_config_header). includes может быть использован для других ключей cpp, а не только для `-i'. например, эта переменная используется для передачи специальных ключей `-d' вашему компилятору.

compile

эта команда используется для компиляции исходных файлов на языке c. имя файла исходных текстов добавляется для формирования полной командной строки.

link

эта команда используется для компоновки программы на языке c.

поддержка yacc и lex

в 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. если вы обнаружили, что какой-нибудь генератор парсеров использует символы, не указанные в этом списке, то сообщите нам новое имя, чтобы мы добавили его.

поддержка c++

automake полностью поддерживает c++.

любой пакет, содержащий код на c++, должен определить переменную `cxx' в файле `configure.in'; самым простым способом сделать это является использование макроса ac_prog_cxx (see section `проверка отдельных программ' in руководство autoconf).

несколько дополнительных переменных определяются при обнаружении исходных файлов на c++:

cxx

имя компилятора c++.

cxxflags

флаги, передаваемые компилятору c++.

cxxcompile

команда, используемая для компиляции исходных текстов на языке c++. имя файла с исходным текстом добавляется к ней для формирования полной командной строки.

cxxlink

эта команда используется для компоновки программы на c++.

поддержка fortran 77

automake полностью поддерживает fortran 77.

любой пакет, содержащий исходные тексты на языке fortran 77, должен определить выходную переменную `f77' в файле `configure.in'; самым простым способом является использование макроса ac_prog_f77 (see section `проверка отдельных программ' in руководство autoconf). see section использование fortran 77 с autoconf.

при использовании исходных текстов на fortran 77 определяются несколько дополнительных переменных:

f77

имя компилятора fortran 77.

fflags

флаги, передаваемые компилятору fortran 77.

rflags

флаги, передаваемые компилятору ratfor.

f77compile

команда, используемая для компиляции исходных текстов на fortran 77. имя файла исходных текстов добавляется к ней чтобы получить полную командную строку.

flink

команда, используемая для компоновки программы на fortran 77 или разделяемой библиотеки.

automake может вдобавок к компиляции выполнять предварительную обработку исходных файлов на fortran 77 и ratfor(1). automake также содержит некоторую поддержку для создания программ и разделяемых библиотек, которые написаны на смеси fortran 77 и других языков (see section использование fortran 77 с c и c++).

это описывается в следующих разделах.

предварительная обработка файлов fortran 77

файл `n.f' автоматически создается из файла `n.f' или `n.r'. это правило запускает препроцессор для преобразования исходных текстов fortran 77 или ratfor с директивами препроцессора в строгий исходный текст fortran 77. вот точные команды, которые используются для этого:

`.f'

$(f77) -f $(defs) $(includes) $(am_cppflags) $(cppflags) $(am_fflags) $(fflags)

`.r'

$(f77) -f $(am_fflags) $(fflags) $(am_rflags) $(rflags)

компиляция файлов fortran 77

`n.o' автоматически создается из `n.f', `n.f' или `n.r' запуском компилятора fortran 77. для компиляции используются следующий команды:

`.f'

$(f77) -c $(am_fflags) $(fflags)

`.f'

$(f77) -c $(defs) $(includes) $(am_cppflags) $(cppflags) $(am_fflags) $(fflags)

`.r'

$(f77) -c $(am_fflags) $(fflags) $(am_rflags) $(rflags)

использование fortran 77 с c и c++

в настоящее время automake предоставляет ограниченную поддержку создания программ и разделяемых библиотек, которые являются смесью fortran 77 и c и/или c++. однако существует много других вопросов, возникающих при смешивании кода на fortran 77 с кодом на других языках, которые в настоящее время не обрабатываются automake, но обрабатываются другими пакетами(2).

automake может предоставить вам помощь двумя способами:

1. автоматический выбор компоновщика в зависимости от комбинации исходного кода.
2. автоматический выбор флагов компоновщика (например, `-l' и `-l') для передачи автоматически выбранному компоновщику для компоновки с соответствующими внутренними библиотеками и библиотеками времени исполнения fortran 77. эти дополнительные флаги компоновщика fortran 77 выдаются в выходную переменную 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    |         |
                        |         |         |         |
                        +---------+---------+---------+

использование fortran 77 с autoconf

имеющаяся в automake поддержка fortran 77 требует наличия свежей версии autoconf, которая поддерживает fortran 77. полная поддержка fortran 77 была добавлена в autoconf 2.13, так что вы можете использовать эту версию autoconf или более позднюю.

поддержка других языков

в настоящее время automake включает в себя полную поддержку только c, c++ (see section поддержка c++) и fortran 77 (see section поддержка fortran 77). поддержка других языков находится в зачаточном состоянии и будет улучшена по требованию пользователей.

автоматическая де-ansi-фикация

хотя стандарты 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' каталога, где происходит построение. эти зависимости являются специфическими для машины. можете удалить их, если хотите; они будут автоматически пересозданы при следующей сборке.

go to the first, previous, next, last section, table of contents.