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

Re: Best practice for cleaning autotools-generated files?

On Tue, Mar 15, 2011 at 10:29:57PM +0000, Marcin Owsiany wrote:
>  * 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... :-/

while i've heard that the latest dh/cdbs can do this automatically for
you, in a few packages that I maintain where they're still running
dh 5, i keep an AUTOFOO_CRUFT variable in debian rules, and have a small
amount of code in the corresponding build and clean areas to "preserve"
and "unpreserve" these files.  Example:


it's not perfect, but seems to do the trick.  note that this is not a
list of "everythign autofoo creates/modifies", but rather a list
of "everythign that make distclean fails to remove/restore".  It tends
to gather files over time and some of them might no longer apply
in later upstream releases, though there's no harm done apart from
maybe a couple wasted cp operations.

On Tue, Mar 15, 2011 at 10:55:54PM +0000, Neil Williams wrote:
> Other tools, like svn-buildpackage, don't have this problem, via the
> mergeWithUpstream support and/or a ../tarballs/ directory. Not perfect
> but it works.

no, they do have this problem but most people just choose to ignore it
until it causes an FTBFS.  If you build with mergeWithUpstream there is
the same likelihood that cruft gets left around, it just doesn't dirty
your working directory/checkout.  You can still run into problems if
someone downloads the source package from a mirror and tries to a
> I think CMake makes a better job of native packages which need
> autotools-type hand-holding, so I may port to that instead.

IIRC CMake for the most part generates its cruft in a nukable
subdirectory, which makes cleanup significantly simpler.

> Building direct from VCS is a nice idea but sometimes, it just isn't
> worth the pain - let the build system build the tarball and package
> from the tarball. It's just easier. Or just change the build system
> and/or the tool.

IYHO anyway -- I and I'm sure others would probably beg to differ :)


Reply to: