4.8.2 Installation Directory Variables

The following variables specify the directories for package installation, see Variables for Installation Directories, 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.

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:

`make'

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.

`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 datarootdir remains being defined as `${prefix}/share' to depend upon 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 datadir 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|@datadir[@]|$(pkgdatadir)|g' \
             -e 's|@prefix[@]|$(prefix)|g'
     
     autoheader autom4te: Makefile
             rm -f $@ $@.tmp
             $(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:

`@datadir[@]'

The brackets prevent configure from replacing `@datadir@' in the Sed expression itself. Brackets are preferable to a backslash here, since Posix says `\@' is not portable.

`$(pkgdatadir)'

Don't use `@pkgdatadir@'! Use the matching makefile variable instead.

`/'

Don't use `/' in the Sed expressions that replace file names since most likely the variables you use, such as `$(pkgdatadir)', contain `/'. Use a shell metacharacter instead, such as `|'.

special characters

File names, file name components, and the value of VPATH should not contain shell metacharacters or white space. See Special Chars in Variables.

dependency on Makefile

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.

Separated dependencies and single suffix rules

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, for details.

`$(srcdir)'

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:

See Erlang Libraries, for details.