11. 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.

11.1 Emacs Lisp
11.2 Gettext
11.3 Libtool
11.4 Java
11.5 Python

11.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.in' must run AM_PATH_LISPDIR (see section 5.4 Autoconf macros supplied with Automake).

By default Automake will byte-compile all Emacs Lisp source files using the Emacs found by AM_PATH_LISPDIR. If you wish to avoid byte-compiling, simply define the variable ELCFILES to be empty. 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 leave it enabled by default. It is probably better for sites with strange setups to cope for themselves than to make the installation less nice for everybody else.

11.2 Gettext

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

The gettext support in Automake requires the addition of two subdirectories to the package, `intl' and `po'. Automake insures that these directories exist and are mentioned in SUBDIRS.

11.3 Libtool

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

11.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, `.class' files are not included in the distribution.

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 which are used when compiling Java sources:

JAVAC

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

JAVACFLAGS

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

AM_JAVACFLAGS

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'.

JAVAROOT

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

CLASSPATH_ENV

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

11.5 Python

Automake provides support for Python compilation with the `PYTHON' primary.

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 byte-compiled (`.pyo') 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.

Automake ships with an Autoconf macro called AM_PATH_PYTHON which will determine some Python-related directory variables (see below). If have called AM_PATH_PYTHON from you `configure.in', then you may use the following variables to list you Python source files in your variables: `python_PYTHON', `pkgpython_PYTHON', `pkgpython_PYTHON', `pyexecdir_PYTHON', `pkgpyexecdir_PYTHON', depending where you want your files installed.

AM_PATH_PYTHON takes a single optional argument. This argument, if present, is the minimum version of Python which can be used for this package. If the version of Python found on the system is older than the required version, then AM_PATH_PYTHON will cause an error.

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

PYTHON

The name of the Python executable.

PYTHON_VERSION

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

PYTHON_PREFIX

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

PYTHON_EXEC_PREFIX

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

PYTHON_PLATFORM

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.

pythondir

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

pkgpythondir

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

pyexecdir

This is the directory where Python extension modules (shared libraries) should be installed.

pkgpyexecdir

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