[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10. Other GNU Tools

Since Automake is primarily intended to generate `Makefile.in's for use in GNU programs, it tries hard to interoperate with other GNU tools.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10.1 Emacs Lisp

Automake provides some support for Emacs Lisp. The LISP primary is used to hold a list of `.el' files. Possible prefixes for this primary are lisp_ and noinst_. Note that if lisp_LISP is defined, then `configure.ac' must run AM_PATH_LISPDIR (see section Autoconf macros supplied with Automake).

Lisp sources are not distributed by default. You can prefix the LISP primary with dist_, as in dist_lisp_LISP or dist_noinst_LISP, to indicate that these files should be distributed.

Automake will byte-compile all Emacs Lisp source files using the Emacs found by AM_PATH_LISPDIR, if any was found.

Byte-compiled Emacs Lisp files are not portable among all versions of Emacs, so it makes sense to turn this off if you expect sites to have more than one version of Emacs installed. Furthermore, many packages don't actually benefit from byte-compilation. Still, we recommend that you byte-compile your Emacs Lisp sources. It is probably better for sites with strange setups to cope for themselves than to make the installation less nice for everybody else.

There are two ways to avoid byte-compiling. Historically, we have recommended the following construct.

lisp_LISP = file1.el file2.el

ELCFILES is an internal Automake variable that normally lists all `.elc' files that must be byte-compiled. Automake defines ELCFILES automatically from lisp_LISP. Emptying this variable explicitly prevents byte-compilation.

Since Automake 1.8, we now recommend using lisp_DATA instead. As in

lisp_DATA = file1.el file2.el

Note that these two constructs are not equivalent. _LISP will not install a file if Emacs is not installed, while _DATA will always install its files.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10.2 Gettext

If AM_GNU_GETTEXT is seen in `configure.ac', then Automake turns on support for GNU gettext, a message catalog system for internationalization (see (gettext)Top section `Introduction' in GNU gettext utilities).

The gettext support in Automake requires the addition of one or two subdirectories to the package: `po' and possibly also `intl'. The latter is needed if AM_GNU_GETTEXT is not invoked with the `external' argument, or if AM_GNU_GETTEXT_INTL_SUBDIR is used. Automake ensures that these directories exist and are mentioned in SUBDIRS.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10.3 Libtool

Automake provides support for GNU Libtool (see (libtool)Top section `Introduction' in The Libtool Manual) with the LTLIBRARIES primary. See section Building a Shared Library.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10.4 Java

Automake provides some minimal support for Java compilation with the JAVA primary.

Any `.java' files listed in a _JAVA variable will be compiled with JAVAC at build time. By default, `.java' files are not included in the distribution, you should use the dist_ prefix to distribute them.

Here is a typical setup for distributing `.java' files and installing the `.class' files resulting from their compilation.

javadir = $(datadir)/java
dist_java_JAVA = a.java b.java …

Currently Automake enforces the restriction that only one _JAVA primary can be used in a given `Makefile.am'. The reason for this restriction is that, in general, it isn't possible to know which `.class' files were generated from which `.java' files, so it would be impossible to know which files to install where. For instance, a `.java' file can define multiple classes; the resulting `.class' file names cannot be predicted without parsing the `.java' file.

There are a few variables that are used when compiling Java sources:


The name of the Java compiler. This defaults to `javac'.


The flags to pass to the compiler. This is considered to be a user variable (see section Variables reserved for the user).


More flags to pass to the Java compiler. This, and not JAVACFLAGS, should be used when it is necessary to put Java compiler flags into `Makefile.am'.


The value of this variable is passed to the `-d' option to javac. It defaults to `$(top_builddir)'.


This variable is a shell expression that is used to set the CLASSPATH environment variable on the javac command line. (In the future we will probably handle class path setting differently.)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

10.5 Python

Automake provides support for Python compilation with the PYTHON primary. A typical setup is to call AM_PATH_PYTHON in `configure.ac' and use a line like the following in `Makefile.am':

python_PYTHON = tree.py leave.py

Any files listed in a _PYTHON variable will be byte-compiled with py-compile at install time. py-compile actually creates both standard (`.pyc') and optimized (`.pyo') byte-compiled versions of the source files. Note that because byte-compilation occurs at install time, any files listed in noinst_PYTHON will not be compiled. Python source files are included in the distribution by default, prepend nodist_ (as in nodist_python_PYTHON) to omit them.

Automake ships with an Autoconf macro called AM_PATH_PYTHON that will determine some Python-related directory variables (see below). If you have called AM_PATH_PYTHON from `configure.ac', then you may use the variables python_PYTHON or pkgpython_PYTHON to list Python source files in your `Makefile.am', depending on where you want your files installed (see the definitions of pythondir and pkgpythondir below).


Search for a Python interpreter on the system. This macro takes three optional arguments. The first argument, if present, is the minimum version of Python required for this package: AM_PATH_PYTHON will skip any Python interpreter that is older than VERSION. If an interpreter is found and satisfies VERSION, then ACTION-IF-FOUND is run. Otherwise, ACTION-IF-NOT-FOUND is run.

If ACTION-IF-NOT-FOUND is not specified, as in the following example, the default is to abort configure.


This is fine when Python is an absolute requirement for the package. If Python >= 2.5 was only optional to the package, AM_PATH_PYTHON could be called as follows.

AM_PATH_PYTHON([2.5],, [:])

AM_PATH_PYTHON creates the following output variables based on the Python installation found during configuration.


The name of the Python executable, or `:' if no suitable interpreter could be found.

Assuming ACTION-IF-NOT-FOUND is used (otherwise `./configure' will abort if Python is absent), the value of PYTHON can be used to setup a conditional in order to disable the relevant part of a build as follows.

  AM_PATH_PYTHON(,, [:])

The Python version number, in the form major.minor (e.g., `2.5'). This is currently the value of `sys.version[:3]'.


The string `${prefix}'. This term may be used in future work that needs the contents of Python's `sys.prefix', but general consensus is to always use the value from configure.


The string `${exec_prefix}'. This term may be used in future work that needs the contents of Python's `sys.exec_prefix', but general consensus is to always use the value from configure.


The canonical name used by Python to describe the operating system, as given by `sys.platform'. This value is sometimes needed when building Python extensions.


The directory name for the `site-packages' subdirectory of the standard Python install tree.


This is the directory under pythondir that is named after the package. That is, it is `$(pythondir)/$(PACKAGE)'. It is provided as a convenience.


This is the directory where Python extension modules (shared libraries) should be installed. An extension module written in C could be declared as follows to Automake:

pyexec_LTLIBRARIES = quaternion.la
quaternion_SOURCES = quaternion.c support.c support.h
quaternion_la_LDFLAGS = -avoid-version -module

This is a convenience variable that is defined as `$(pyexecdir)/$(PACKAGE)'.

All these directory variables have values that start with either `${prefix}' or `${exec_prefix}' unexpanded. This works fine in `Makefiles', but it makes these variables hard to use in `configure'. This is mandated by the GNU coding standards, so that the user can run `make prefix=/foo install'. The Autoconf manual has a section with more details on this topic (see (autoconf)Installation Directory Variables section `Installation Directory Variables' in The Autoconf Manual). See also Installing to Hard-Coded Locations.

[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated on July, 20 2009 using texi2html 1.76.