The following variables specify the directories for
package installation, see Variables for
Installation Directories in The GNU Coding
Standards, for more information. Each variable corresponds to an
argument of configure; trailing slashes are stripped so that
expressions such as ‘${prefix}/lib’ expand with only one slash
between directory names. See the end of this section for
details on when and how to use these variables.
The directory for installing executables that users run.
The directory for installing idiosyncratic read-only architecture-independent data.
The root of the directory tree for read-only architecture-independent data files.
The directory for installing documentation files (other than Info and man).
The directory for installing documentation files in DVI format.
The installation prefix for architecture-dependent files. By default
it’s the same as prefix. You should avoid installing anything
directly to exec_prefix. However, the default value for
directories containing architecture-dependent files should be relative
to exec_prefix.
The directory for installing HTML documentation.
The directory for installing C header files.
The directory for installing documentation in Info format.
The directory for installing object code libraries.
The directory for installing executables that other programs run.
The directory for installing locale-dependent but architecture-independent data, such as message catalogs. This directory usually has a subdirectory per locale.
The directory for installing modifiable single-machine data. Content in this directory typically survives a reboot.
The directory for installing temporary modifiable single-machine data.
Content in this directory survives as long as the process is running
(such as pid files), as contrasted with /tmp that may be
periodically cleaned. Conversely, this directory is typically cleaned
on a reboot. By default, this is a subdirectory of
localstatedir.
The top-level directory for installing documentation in man format.
The directory for installing C header files for non-GCC compilers.
The directory for installing PDF documentation.
The common installation prefix for all files. If exec_prefix
is defined to a different value, prefix is used only for
architecture-independent files.
The directory for installing PostScript documentation.
The directory for installing executables that system administrators run.
The directory for installing read-only single-machine data.
Most of these variables have values that rely on prefix or
exec_prefix. It is deliberate that the directory output
variables keep them unexpanded: typically ‘@datarootdir@’ is
replaced by ‘${prefix}/share’, not ‘/usr/local/share’, and
‘@datadir@’ is replaced by ‘${datarootdir}’.
This behavior is mandated by the GNU Coding Standards, so that when the user runs:
she can still specify a different prefix from the one specified to
configure, in which case, if needed, the package should hard
code dependencies corresponding to the make-specified prefix.
she can specify a different installation location, in which case the package must still depend on the location which was compiled in (i.e., never recompile when ‘make install’ is run). This is an extremely important feature, as many people may decide to install all the files of a package grouped together, and then install links from the final locations to there.
In order to support these features, it is essential that
datarootdir remains defined as ‘${prefix}/share’,
so that its value can be expanded based
on the current value of prefix.
A corollary is that you should not use these variables except in
makefiles. For instance, instead of trying to evaluate datadir
in configure and hard-coding it in makefiles using
e.g., ‘AC_DEFINE_UNQUOTED([DATADIR], ["$datadir"], [Data directory.])’,
you should add
-DDATADIR='$(datadir)' to your makefile’s definition of
CPPFLAGS (AM_CPPFLAGS if you are also using Automake).
Similarly, you should not rely on AC_CONFIG_FILES to replace
bindir and friends in your shell scripts and other files; instead,
let make manage their replacement. For instance Autoconf
ships templates of its shell scripts ending with ‘.in’, and uses a
makefile snippet similar to the following to build scripts like
autoheader and autom4te:
edit = sed \
-e 's|@bindir[@]|$(bindir)|g' \
-e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \
-e 's|@prefix[@]|$(prefix)|g'
autoheader autom4te: Makefile
rm -f $@ $@.tmp
srcdir=''; \
test -f ./$@.in || srcdir=$(srcdir)/; \
$(edit) $${srcdir}$@.in >$@.tmp
chmod +x $@.tmp
chmod a-w $@.tmp
mv $@.tmp $@
autoheader: $(srcdir)/autoheader.in autom4te: $(srcdir)/autom4te.in
Some details are noteworthy:
The brackets prevent configure from replacing
‘@bindir@’ in the Sed expression itself.
Brackets are preferable to a backslash here, since
Posix says ‘\@’ is not portable.
Don’t use ‘@bindir@’! Use the matching makefile variable instead.
The example takes advantage of the variable ‘$(pkgdatadir)’ provided by Automake; it is equivalent to ‘$(datadir)/$(PACKAGE)’.
Don’t use ‘/’ in the Sed expressions that replace file names since most likely the variables you use, such as ‘$(bindir)’, contain ‘/’. Use a shell metacharacter instead, such as ‘|’.
File names, file name components, and the value of VPATH should
not contain shell metacharacters or white
space. See Special Characters in Output Variables.
Since edit uses values that depend on the configuration specific
values (prefix, etc.) and not only on VERSION and so forth,
the output depends on Makefile, not configure.ac.
The main rule is generic, and uses ‘$@’ extensively to avoid the need for multiple copies of the rule.
You can’t use them! The above snippet cannot be (portably) rewritten as:
autoconf autoheader: Makefile
.in:
rm -f $@ $@.tmp
$(edit) $< >$@.tmp
chmod +x $@.tmp
mv $@.tmp $@
See Single Suffix Rules and Separated Dependencies, for details.
Be sure to specify the name of the source directory, otherwise the package won’t support separated builds.
For the more specific installation of Erlang libraries, the following variables are defined:
The common parent directory of Erlang library installation directories.
This variable is set by calling the AC_ERLANG_SUBST_INSTALL_LIB_DIR
macro in configure.ac.
The installation directory for Erlang library library. This variable is set by using the ‘AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR’ macro in configure.ac.
See Erlang Libraries, for details.