How thorough must the clean target be?
A recent bug report prompted this question, which had been growing in the
back of my mind for some time.
Some packages run Autconf or Automake at build time, either because they
patch the build machinery or because the package is a CVS snapshot that
doesn't contain any derived files. My gnubg package is an example of
this. Currently, there are two methods for dealing with this, both of
which are blessed by the autotools-dev documentation: run Autoconf and
Automake beforehand and let the Debian *.diff.gz be huge, or run Autoconf
and Automake at build time. Both approaches have strong advocates, and I
think it's fair to say that previous debian-devel conversation has not
reached a project-wide consensus that one approach is better than the
other.
However, the current debian-policy statement about clean is:
This must undo any effects that the build and binary targets may have
had, except that it should leave alone any output files created in the
parent directory by a run of a binary target.
Taken exactly literally, this says that packages that run Autoconf or
Automake at build time must be able to reverse all changes that those
tools make when the clean target is run. Similarly, packages that copy
new config.sub or config.guess files at build time must save the old
versions and restore them when the clean target is run.
In practice, I think that would rule out running Autoconf and Automake at
build time except for simple packages, as those programs make fairly
widespread changes.
I'm not sure that's really what's intended, though. But maybe it is.
Thoughts on this?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: