| [ < ] | [ > ] | [ << ] | [ 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 multilibs. |
| [ < ] | [ > ] | [ << ] | [ 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 rules will be generated for the directory.
All files listed using the _SOURCES, _HEADERS, and
_LISP primaries will be used to generate tags. Note that
generated source files that are not distributed must be declared in
variables like nodist_noinst_HEADERS or
nodist_prog_SOURCES or they will be ignored.
A tags rule will be output at the topmost directory of a
multi-directory package. When run from this topmost directory,
`make tags' will generate a `TAGS' file that includes by
reference all `TAGS' files from subdirectories.
The tags rule will also be generated if the variable
ETAGS_ARGS is defined. This variable is intended for use in
directories that 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 file names to ETAGS_ARGS, you will probably also
want to define TAGS_DEPENDENCIES. The contents of this variable
are added directly to the dependencies for the tags rule.
Automake also generates a ctags rule that can be used to
build vi-style `tags' files. The variable CTAGS
is the name of the program to invoke (by default ctags);
CTAGSFLAGS can be used by the user to pass additional flags,
and AM_CTAGSFLAGS can be used by the `Makefile.am'.
Automake will also generate an ID rule that will run
mkid on the source. This is only supported on a
directory-by-directory basis.
Finally, Automake also emits rules to support the
GNU Global Tags program.
The GTAGS rule runs Global Tags and puts the
result in the top build directory. The variable GTAGS_ARGS
holds arguments that 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 that could compile `.foo' files to `.o' files. You would simply define a 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 out which extensions you are defining your
suffix rule for. This usually happens when your extension 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 from misinterpreting the `.idlC.cpp:' rule as an attempt to transform `.idlC' files into `.cpp' files.
SUFFIXES = .idl C.cpp
.idlC.cpp:
# whatever
|
As you may have noted, the SUFFIXES variable 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 that 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] | [ ? ] |
This document was generated on July, 20 2009 using texi2html 1.76.