Next: Install Command Categories, Previous: Directory Variables, Up: Makefile Conventions
See Standard Targets.
A few standard Makefile goals are worth more comments.
all
install-strip
below.
install
install-exec
and
install-data
. On sites having mixed CPU architectures,
install-exec
should install everything which is architecture
specific, while install-data
should install files common to all
architectures. When installing on multiple architectures after the
first, this would avoid having to rewrite all the .info files,
etc., on arches after the first (letter from Karl, 1995-05-13). Of
course, making install
is equivalent to installing everything
at once. Automake complies with this part of Gnits Standards.
For installing Info files, GNU standards mandate using:
-if test -f foo.info; then d=.; \ else d=$(srcdir); fi; \
which is only useless complexity. Info file are always generated in the source directories because they are meant to be later distributed all prepared: they ought to be, per GNU standards. These lines were introduced as an half-hearted attempt to handle hypothetical cases of read-only distributions (thinking about CD-ROMs). These two lines have been confusing to many maintainers, who tried generalising them, introducing various other bugs and contradictions on the way. Richard Stallman more or less agrees it was an error to have this trickery in GNU standards, but is reluctant to remove it, because he says it hurts nothing and he has more urgent things to do (yet he easily spent, arguing, many hundred times the energy it would have taken to kill the lines).
Info files installation per GNU standards has another huge ugliness:
it asks us to write rules relying on an unexisting, or at least
unavailable, install-info
program. Such programs are being
written by people, and later rejected by the FSF for various reasons
(wrong specifications, wrong implementation language, wrong legalese,
etc.) While this is being done and undone, demands to maintainers
through GNU standards are changing, and we kept updating our
Makefile.ins and Texinfo files for no real purpose. Some of us
are loosing time at conformance, while the matter is not even set.
But by now, it seems that members of Gnits just does not call
install-info
, and provide, near the beginning of each Texinfo
file, the image of the suggested dir menu items like this:
@ifinfo @format START-INFO-DIR-ENTRY * direntry-1 * direntry-2 ... END-INFO-DIR-ENTRY @end format @end ifinfo
The direntry lines, which really are menu items, ideally give easy pointers for the whole package, as well as one per program the package installs (so the command `info name' works).
Richard Stallman has supposedly been writing a new install-info
program, accompanied by changes to Texinfo so we might write instead:
@dircategory <whatever> (we'll have to dream up a list of categories) @direntry * direntry-1 * direntry-2 ... @end direntry
(letter from Karl, 1996-09-09).
In the meantime, we do not bracket dir entries in support of an
always evanescent install-info
program. We are just not
interested at working right away at improving the functionality of
hurded software. Let it become available first!
However, just consider that it is a good idea that every maintainer
use some brackets as a uniform way to document the set of
dir entries they want to suggest for their package. This
purpose is acceptable. Let's stick to `START-INFO-DIR-ENTRY' and
`END-INFO-DIR-ENTRY', until a working solution gets fully
available to the GNU community. In this particular case, it seems
that the mere statement in GNU standards brought us nowhere, and
slowly.
install-strip
In their environment, they may permanently setup at login time some
definitions, using code similar to this one (sh
syntax):
export INSTALL_DATA; INSTALL_DATA='install -m 644' export INSTALL_PROGRAM; INSTALL_PROGRAM='install -m 755 -s' export INSTALL_SCRIPT; INSTALL_SCRIPT='install -m 755'
so the default behaviour they want is enforced automatically, and
without ugly diagnostics while installing scripts. Automake complies with this part of Gnits Standards.
clean
distclean
maintainer-clean
The distclean
goal, in spirit, is for bringing a distribution
back to distribution state. This is a useful goal people should use
before reconfiguring a directory for a different architecture, but it
is less useful when people are using different build directories, one
per architecture, when their make
permits of course. As for
the maintainer-clean
goal, it is not for users and
installers, generally. You may need fairly special tools to reshape a
distribution after a maintainer-clean
. Some installers
stubbornly insist for using it, and submit reports about it. Please,
let it plainly be their problem. By considering their reports, you
are encouraging the abuse.
As parallel make
goes, we want all the mostlyclean
s from
done before all the clean
s, themselves before all the
distclean
s. Dependencies over some configuration files like
config.status force us to be very careful at removing them only
last, especially when recursive make
is involved.
Automake complies with this part of Gnits Standards.
GNU Standards require a bit of interpretation, here. If Richard put
that (ID and) TAGS should be removed in
maintainer-clean
, this is only because he traditionally
packaged a ready TAGS in his own distributions, so it would not
make sense removing these in distclean
if this goal should
merely bring back the package to distribution state.
However, if ID and TAGS are not being
distributed, as it seems to be the current trend, these have to be
built after the unpacking, so removing them within distclean
makes perfect sense, and the GNU Standards are just a bit oldish on
these things.
I wonder how difficult it would be for Automake to know somewhat
whether ID or TAGS are meant to be distributed in a
package, or not, and decide where to remove these, accordingly.
check
check
goal should only be
built when actually checking (letter from Tom, 1996-01-24). Automake
offers the check_PROGRAMS
macro for making this easy.
One possibility for `make check' is to use DejaGNU. Properly
written DejaGNU test suites can be run even when the program is
cross-compiled, by copying the program to an appropriate host and
running there (letter from Tom, 1996-01-24). But DejaGNU requires
TCL, so checking through DejaGNU is fairly demanding, and put
`make check' more among the maintainer goals than among the
installer goals. Automake offers alternate means so it is possible to
write checks available to all installers. We should prefer, and by
far, offering `make check' as an installer goal.
id
tags
ID
TAGS
id
should have ID
as its sole dependency,
so the command `make id' will regenerate the project's ID
file. A goal named tags
should have TAGS
as its sole
dependency, so the command `make tags' will regenerate the
project's TAGS file.
In a distribution having a shallow or deep directory structure, ID and TAGS files may be generated in more than one subdirectory. At the top-level, a global TAGS should be generated which uses the include feature for making all tags available at once. Automake currently implements this solution, which is satisfying so far.
GNU Standards do not speak of ID at all. GNU Standards are unclear, or at least fuzzy, about the fact TAGS should be part of distributions or not. Gnits members do not read GNU Standards all the same way on this particular aspect.
It seems that the current trend is to not distribute ID and TAGS files, but leave goals so the installer can rebuild them easily, if needed. Whether a package distributes TAGS, it should also distribute ID. If it does not distribute TAGS, it should not distribute ID either.
We may question the utility of distributing pre-made ID or
TAGS files. People using them will be programmers.
Programmers who know what to do with an ID file will have
mkid
installed—in fact, one can't even use an ID file
unless mkid
(and therefore lid
) is installed. People
who use TAGS will be emacs
-users, and will therefore
have etags
installed, and they'll know how to type `make
TAGS'. So, in the interest of fighting distribution bloat, we don't
think either ID or TAGS files should be in the
distribution (letter from Greg, 1996-02-20).