14.1 Where files are installed

If you've ever run configure --help, you've probably been frightened by the huge number of options offered. Although nobody ever uses more than two or three of these, they are still important to understand when writing your package; their proper use will help you figure out where each file should be installed. For a background on these standard directories and their uses, refer to 3. How to run configure and make.

We do recommend using the standard directories as described. While most package builders only use `--prefix' or perhaps `--exec-prefix', some packages (eg. GNU/Linux distributions) require more control. For instance, if your package `quux' puts a file into sysconfigdir, then in the default configuration it will end up in `/usr/local/var'. However, for a GNU/Linux distribution it would make more sense to configure with `--sysconfigdir=/var/quux'.

Automake makes it very easy to use the standard directories. Each directory, such as `bindir', is mapped onto a `Makefile' variable of the same name. Automake adds three useful variables to the standard list:

pkgincludedir

This is a convenience variable whose value is `$(includedir)/$(PACKAGE)'.

pkgdatadir

A convenience variable whose value is `$(datadir)/$(PACKAGE)'.

pkglibdir

A variable whose value is `$(libdir)/$(PACKAGE)'.

These cannot be set on the configure command line but are always defined as above. (29)

In Automake, a directory variable's name, without the `dir' suffix, can be used as a prefix to a primary to indicate install location. Confused yet? And example will help: items listed in `bin_PROGRAMS' are installed in `bindir'.

Automake's rules are actually a bit more precise than this: the directory and the primary must agree. It doesn't make sense to install a library in `datadir', so Automake won't let you. Here is a complete list showing primaries and the directories which can be used with them:

`PROGRAMS'

`bindir', `sbindir', `libexecdir', `pkglibdir'.

`LIBRARIES'

`libdir', `pkglibdir'.

`LTLIBRARIES'

`libdir', `pkglibdir'.

`SCRIPTS'

`bindir', `sbindir', `libexecdir', `pkgdatadir'.

`DATA'

`datadir', `sysconfdir', `sharedstatedir', `localstatedir', `pkgdatadir'.

`HEADERS'

`includedir', `oldincludedir', `pkgincludedir'.

`TEXINFOS'

`infodir'.

`MANS'

`man', `man0', `man1', `man2', `man3', `man4', `man5', `man6', `man7', `man8', `man9', `mann', `manl'.

There are two other useful prefixes which, while not directory names, can be used in their place. These prefixes are valid with any primary. The first of these is `noinst'. This prefix tells Automake that the listed objects should not be installed, but should be built anyway. For instance, you can use `noinst_PROGRAMS' to list programs which will not be installed.

The second such non-directory prefix is `check'. This prefix tells Automake that this object should not be installed, and furthermore that it should only be built when the user runs make check.

Early in Automake history we discovered that even Automake's extended built-in list of directories was not enough -- basically anyone who had written a `Makefile.am' sent in a bug report about this. Now Automake lets you extend the list of directories.

First you must define your own directory variable. This is a macro whose name ends in `dir'. Define this variable however you like. We suggest that you define it relative to an autoconf directory variable; this gives the user some control over the value. Don't hardcode it to something like `/etc'; absolute hardcoded paths are rarely portable.

Now you can attach the base part of the new variable to a primary just as you can with the built-in directories:

foodir = $(datadir)/foo foo_DATA = foo.txt

Automake lets you attach such a variable to any primary, so you can do things you ordinarily wouldn't want to do or be allowed to do. For instance, Automake won't diagnose this piece of code that tries to install a program in an architecture-independent location:

foodir = $(datadir)/foo foo_PROGRAMS = foo