| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [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'.
| 12.1 Basics of Installation | What gets installed where | |
| 12.2 The Two Parts of Install | Installing data and programs separately | |
| 12.3 Extending Installation | Adding your own rules for installation | |
| 12.4 Staged Installs | Installation in a temporary location | |
| 12.5 Install Rules for the User | Useful additional rules |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
For most file types, Automake will install multiple files at once, while
avoiding command line length issues (see section Staying below the command line length limit). Since
some install programs will not install the same file twice in
one invocation, you may need to ensure that file lists are unique within
one variable such as `nobase_include_HEADERS' above.
You should not rely on the order in which files listed in one variable are installed. Likewise, to cater for parallel make, you should not rely on any particular file installation order even among different file types (library dependencies are an exception here).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section Extending Automake Rules, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 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 (standards)Makefile Conventions section `Makefile Conventions' in The GNU Coding Standards, for another usage example.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on July, 20 2009 using texi2html 1.76.