7.2.5 Standard Targets for Users

See Standard Targets.

A few standard Makefile goals are worth more comments.

all

Despite what GNU standards say, many maintainers are quite attentive to not use `-g' while linking. On a few systems (Linux in particular), this creates binaries unable to take advantage of shared libraries when later installed, yielding unacceptably big binaries. Also see install-strip below.

install

This goal should be further subdivided in 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

This goal should of course supported for mere compliance, yet it is not very useful as designed. GNU standards speak of Users who don't mind being helpless and Devil-may-care users, and this biased wording and thinking let us guess that GNU standards did not overly try being helpful at it. Nearly everybody prefer all their binaries installed stripped by default, so there is an alternative mechanism in Gnits that installers might like.

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

It seems that many of us have difficulty understanding exactly where a particular derived file should be removed. Here are some practical rules which would help taking such decisions.

• If `make all' did it, `make clean' removes it.
• If `./configure' did it, `make distclean' removes it.
• If you did it, `make maintainer-clean' removes it :-).

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 mostlycleans from done before all the cleans, themselves before all the distcleans. 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

Programs which are only used by the 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

A goal named 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).