|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
If you’ve ever run
configure --help, you’ve probably been
frightened by the huge number of options offered. Although nobody ever
uses more than two or three of these, they are still important to
understand when writing your package; their proper use will help you
figure out where each file should be installed. For a background on
these standard directories and their uses, refer to How to run configure and make.
We do recommend using the standard directories as described. While most
package builders only use ‘--prefix’ or perhaps
‘--exec-prefix’, some packages (eg. GNU/Linux distributions)
require more control. For instance, if your package ‘quux’ puts a
sysconfigdir, then in the default configuration it will
end up in ‘/usr/local/var’. However, for a GNU/Linux
distribution it would make more sense to configure with
Automake makes it very easy to use the standard directories. Each directory, such as ‘bindir’, is mapped onto a ‘Makefile’ variable of the same name. Automake adds three useful variables to the standard list:
This is a convenience variable whose value is ‘$(includedir)/$(PACKAGE)’.
A convenience variable whose value is ‘$(datadir)/$(PACKAGE)’.
A variable whose value is ‘$(libdir)/$(PACKAGE)’.
These cannot be set on the
configure command line but are always
defined as above. (29)
In Automake, a directory variable’s name, without the ‘dir’ suffix, can be used as a prefix to a primary to indicate install location. Confused yet? And example will help: items listed in ‘bin_PROGRAMS’ are installed in ‘bindir’.
Automake’s rules are actually a bit more precise than this: the directory and the primary must agree. It doesn’t make sense to install a library in ‘datadir’, so Automake won’t let you. Here is a complete list showing primaries and the directories which can be used with them:
‘bindir’, ‘sbindir’, ‘libexecdir’, ‘pkglibdir’.
‘bindir’, ‘sbindir’, ‘libexecdir’, ‘pkgdatadir’.
‘datadir’, ‘sysconfdir’, ‘sharedstatedir’, ‘localstatedir’, ‘pkgdatadir’.
‘includedir’, ‘oldincludedir’, ‘pkgincludedir’.
‘man’, ‘man0’, ‘man1’, ‘man2’, ‘man3’, ‘man4’, ‘man5’, ‘man6’, ‘man7’, ‘man8’, ‘man9’, ‘mann’, ‘manl’.
There are two other useful prefixes which, while not directory names, can be used in their place. These prefixes are valid with any primary. The first of these is ‘noinst’. This prefix tells Automake that the listed objects should not be installed, but should be built anyway. For instance, you can use ‘noinst_PROGRAMS’ to list programs which will not be installed.
The second such non-directory prefix is ‘check’. This prefix tells
Automake that this object should not be installed, and furthermore that
it should only be built when the user runs
Early in Automake history we discovered that even Automake’s extended built-in list of directories was not enough – basically anyone who had written a ‘Makefile.am’ sent in a bug report about this. Now Automake lets you extend the list of directories.
First you must define your own directory variable. This is a macro whose name ends in ‘dir’. Define this variable however you like. We suggest that you define it relative to an autoconf directory variable; this gives the user some control over the value. Don’t hardcode it to something like ‘/etc’; absolute hardcoded paths are rarely portable.
Now you can attach the base part of the new variable to a primary just as you can with the built-in directories:
foodir = $(datadir)/foo foo_DATA = foo.txt
Automake lets you attach such a variable to any primary, so you can do things you ordinarily wouldn’t want to do or be allowed to do. For instance, Automake won’t diagnose this piece of code that tries to install a program in an architecture-independent location:
foodir = $(datadir)/foo foo_PROGRAMS = foo
|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]|
This document was generated by Ben Elliston on July 10, 2015 using texi2html 1.82.