[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are a few rules and variables that didn't fit anywhere else.
18.1 Interfacing to etags
Interfacing to etags and mkid 18.2 Handling new file extensions 18.3 Support for Multilibs Support for multilibbing.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
etags
Automake will generate rules to generate `TAGS' files for use with GNU Emacs under some circumstances.
If any C, C++ or Fortran 77 source code or headers are present, then
tags
and TAGS
targets will be generated for the directory.
At the topmost directory of a multi-directory package, a tags
target file will be generated which, when run, will generate a
`TAGS' file that includes by reference all `TAGS' files from
subdirectories.
The tags
target will also be generated if the variable
ETAGS_ARGS
is defined. This variable is intended for use in
directories which contain taggable source that etags
does not
understand. The user can use the ETAGSFLAGS
to pass additional
flags to etags
; AM_ETAGSFLAGS
is also available for use in
`Makefile.am'.
Here is how Automake generates tags for its source, and for nodes in its Texinfo file:
ETAGS_ARGS = automake.in --lang=none \ --regex='/^@node[ \t]+\([^,]+\)/\1/' automake.texi |
If you add filenames to `ETAGS_ARGS', you will probably also
want to set `TAGS_DEPENDENCIES'. The contents of this variable
are added directly to the dependencies for the tags
target.
Automake will also generate an ID
target which will run
mkid
on the source. This is only supported on a
directory-by-directory basis.
Automake also supports the GNU Global Tags program. The GTAGS
target runs Global Tags
automatically and puts the result in the top build directory. The
variable GTAGS_ARGS
holds arguments which are passed to
gtags
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is sometimes useful to introduce a new implicit rule to handle a file type that Automake does not know about.
For instance, suppose you had a compiler which could compile `.foo' files to `.o' files. You would simply define an suffix rule for your language:
.foo.o: foocc -c -o $@ $< |
Then you could directly use a `.foo' file in a `_SOURCES' variable and expect the correct results:
bin_PROGRAMS = doit doit_SOURCES = doit.foo |
This was the simpler and more common case. In other cases, you will
have to help Automake to figure which extensions you are defining your
suffix rule for. This usually happens when your extensions does not
start with a dot. Then, all you have to do is to put a list of new
suffixes in the SUFFIXES
variable before you define your
implicit rule.
For instance the following definition prevents Automake to misinterpret `.idlC.cpp:' as an attemp to transform `.idlC' into `.cpp'.
SUFFIXES = .idl C.cpp .idlC.cpp: # whatever |
As you may have noted, the SUFFIXES
macro behaves like the
.SUFFIXES
special target of make
. You should not touch
.SUFFIXES
yourself, but use SUFFIXES
instead and let
Automake generate the suffix list for .SUFFIXES
. Any given
SUFFIXES
go at the start of the generated suffixes list, followed
by Automake generated suffixes not already in the list.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automake has support for an obscure feature called multilibs. A multilib is a library which is built for multiple different ABIs at a single time; each time the library is built with a different target flag combination. This is only useful when the library is intended to be cross-compiled, and it is almost exclusively used for compiler support libraries.
The multilib support is still experimental. Only use it if you are familiar with multilibs and can debug problems you might encounter.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |