Next: What Gets Cleaned, Previous: Building documentation, Up: GNU Automake [Contents][Index]
Naturally, Automake handles the details of actually installing your program once it has been built. All files named by the various primaries are automatically installed in the appropriate places when the user runs ‘make install’.
A file named in a primary is installed by copying the built file into the appropriate directory. The base name of the file is used when installing.
bin_PROGRAMS = hello subdir/goodbye
In this example, both ‘hello’ and ‘goodbye’ will be installed in ‘$(bindir)’.
Sometimes it is useful to avoid the basename step at install time. For
instance, you might have a number of header files in subdirectories of
the source tree that are laid out precisely how you want to install
them. In this situation you can use the nobase_
prefix to
suppress the base name step. For example:
nobase_include_HEADERS = stdio.h sys/types.h
will install stdio.h in ‘$(includedir)’ and types.h in ‘$(includedir)/sys’.
Automake generates separate install-data
and install-exec
rules, in case the installer is installing on multiple machines that
share directory structure—these targets allow the machine-independent
parts to be installed only once. install-exec
installs
platform-dependent files, and install-data
installs
platform-independent files. The install
target depends on both
of these targets. While Automake tries to automatically segregate
objects into the correct category, the Makefile.am author is, in
the end, responsible for making sure this is done correctly.
Variables using the standard directory prefixes ‘data’,
‘info’, ‘man’, ‘include’, ‘oldinclude’,
‘pkgdata’, or ‘pkginclude’ are installed by
install-data
.
Variables using the standard directory prefixes ‘bin’,
‘sbin’, ‘libexec’, ‘sysconf’, ‘localstate’,
‘lib’, or ‘pkglib’ are installed by install-exec
.
For instance, data_DATA
files are installed by install-data
,
while bin_PROGRAMS
files are installed by install-exec
.
Any variable using a user-defined directory prefix with ‘exec’ in
the name (e.g., myexecbin_PROGRAMS
) is installed by
install-exec
. All other user-defined prefixes are installed by
install-data
.
It is possible to extend this mechanism by defining an
install-exec-local
or install-data-local
rule. If these
rules exist, they will be run at ‘make install’ time. These
rules can do almost anything; care is required.
Automake also supports two install hooks, install-exec-hook
and
install-data-hook
. These hooks are run after all other install
rules of the appropriate type, exec or data, have completed. So, for
instance, it is possible to perform post-installation modifications
using an install hook. See Extending Automake Rules, for some examples.
Automake generates support for the DESTDIR
variable in all
install rules. DESTDIR
is used during the ‘make install’
step to relocate install objects into a staging area. Each object and
path is prefixed with the value of DESTDIR
before being copied
into the install area. Here is an example of typical DESTDIR usage:
mkdir /tmp/staging && make DESTDIR=/tmp/staging install
The mkdir
command avoids a security problem if the attacker
creates a symbolic link from /tmp/staging to a victim area;
then make
places install objects in a directory tree built under
/tmp/staging. If /gnu/bin/foo and
/gnu/share/aclocal/foo.m4 are to be installed, the above command
would install /tmp/staging/gnu/bin/foo and
/tmp/staging/gnu/share/aclocal/foo.m4.
This feature is commonly used to build install images and packages (see Building Binary Packages Using DESTDIR).
Support for DESTDIR
is implemented by coding it directly into
the install rules. If your Makefile.am uses a local install
rule (e.g., install-exec-local
) or an install hook, then you
must write that code to respect DESTDIR
.
See Makefile Conventions in The GNU Coding Standards, for another usage example.
Automake also generates rules for targets uninstall
,
installdirs
, and install-strip
.
Automake supports uninstall-local
and uninstall-hook
.
There is no notion of separate uninstalls for “exec” and “data”, as
these features would not provide additional functionality.
Note that uninstall
is not meant as a replacement for a real
packaging tool.
Next: What Gets Cleaned, Previous: Building documentation, Up: GNU Automake [Contents][Index]