Go to the first, previous, next, last section, table of contents.
The following variables specify the directories where the package will
be installed, see section `Variables for Installation Directories' in The GNU Coding Standards, for more information.
See the end of this section for details on when and how to use these
variables.
- Variable: bindir
-
The directory for installing executables that users run.
- Variable: datadir
-
The directory for installing read-only architecture-independent data.
- Variable: exec_prefix
-
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.
- Variable: includedir
-
The directory for installing C header files.
- Variable: infodir
-
The directory for installing documentation in Info format.
- Variable: libdir
-
The directory for installing object code libraries.
- Variable: libexecdir
-
The directory for installing executables that other programs run.
- Variable: localstatedir
-
The directory for installing modifiable single-machine data.
- Variable: mandir
-
The top-level directory for installing documentation in man format.
- Variable: oldincludedir
-
The directory for installing C header files for non-gcc compilers.
- Variable: prefix
-
The common installation prefix for all files. If exec_prefix
is defined to a different value, prefix is used only for
architecture-independent files.
- Variable: sbindir
-
The directory for installing executables that system
administrators run.
- Variable: sharedstatedir
-
The directory for installing modifiable architecture-independent data.
- Variable: sysconfdir
-
The directory for installing read-only single-machine data.
Most of these variables have values that rely on prefix or
exec_prefix. It is on purpose that the directory output
variables keep them unexpanded: typically `@datadir@' will be
replaced by `${prefix}/share', not `/usr/local/share'.
This behavior is mandated by the GNU coding standards, so that when
the user runs:
- `make'
-
she can still specify a different prefix from the one specified to
@command{configure}, in which case, if needed, the package shall hard
code dependencies to her late desires.
- `make install'
-
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 datadir
remains being defined as `${prefix}/share' to depend upon the
current value of prefix.
A corollary is that you should not use these variables but in Makefiles.
For instance, instead of trying to evaluate datadir in
`configure' and hardcoding it in Makefiles using
e.g. `AC_DEFINE_UNQUOTED(DATADIR, "$datadir")', you should add
`-DDATADIR="$(datadir)"' to your CPPFLAGS.
Similarly you should not rely on AC_OUTPUT_FILES to replace
datadir and friends in your shell scripts and other files, rather
let @command{make} manage their replacement. For instance Autoconf
ships templates of its shell scripts ending with `.sh', and uses
this Makefile snippet:
.sh:
rm -f $@ [email protected]
sed 's,@datadir\@,$(pkgdatadir),g' $< >[email protected]
chmod +x [email protected]
mv [email protected] $@
Three things are noteworthy:
- `@datadir\@'
-
The backslash prevents @command{configure} from replacing
`@datadir@' in the sed expression itself.
- `$(pkgdatadir)'
-
Don't use `@pkgdatadir@'! Use the matching makefile variable
instead.
- `,'
-
Don't use `/' in the sed expression(s) since most probably the
variables you use, such as `$(pkgdatadir)', will contain
some.
Go to the first, previous, next, last section, table of contents.