[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Best practice for cleaning autotools-generated files?


The current best practice for dealing with packages using GNU autotools
(as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
run autoreconf in a prerequisite of a build target, and to remove its
results in the clean target.

However that README does not give any hints on how to best do the
cleaning. How are others doing it?

I could think of the following ways:

 * maintain a blacklist of generated files, and "rm" them in the
   clean target.

   This has the downside that as soon as any of:
   - automake
   - aclocal
   - autoconf
   - autopoint
   - autoheader
   - libtoolize
   decides to introduce a new autogenerated file, my package is going to
   collect cruft on a sourceful rebuild (e.g. NMUs). And because of the
   time skew problems, it is cruft which can potentially break the build
   in subtle ways.

   Looking (for example) at the amazing list of files that autopoint
   copies into the po/ subdirectory, I have very little faith that
   something new won't appear in the future.

   The only way this would be acceptable was if there was a way to make
   dpkg-build abort if added files are found outside the debian
   directory. That would cause the person building the package to add
   any new files to the blacklist. OTOH the security team probably
   wouldn't like it?

 * maintain a whitelist of distributed files, and "rm" everything
   else (apart from the debian directory) in the clean target.

   Since I use (or plan to use) git-buildpackage, I don't have a tarball
   which could serve as an authoritative whitelist. Thus an additional
   whitelist refresh step would be required every time I merge the
   upstream branch into the debian branch. That's bad. Furthermore, a
   whitelist approach would mercilessly elliminate all files on a
   "clean", so one would have to be really careful not to leave
   unchecked but precious files in the source tree at any time... :-/

 * for every autoool, maintain an anti-autotool that would know how to
   revert the actions of its counterpart. Basically just like
   automake-generated files encode the knowledge of how to "make clean"
   after a "make all", there would need to be a "-clean" counterpart for
   every autotool that autoreconf can call.

   However this would need to be a team effort, as such cleanup tools
   would need to closely follow their "generator" counterparts.

Are there other ways? Comments?

Marcin Owsiany <porridge@debian.org>             http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Reply to: