Re: Best practice for cleaning autotools-generated files?
On Wed, 16 Mar 2011, Neil Williams wrote:
> On Tue, 15 Mar 2011 23:35:59 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
> > 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.
> > [...]
> >
> > mergeUpstream works only if you never want to look at upstream changes.
>
> Personally, I'll use debdiff on the .dsc to view changes of all types,
> prior to further testing / installation / pbuilder / upload etc. The
> upstream changes are available and, in some ways, having a
> separate ../tarballs/ directory means that I can unpack
> both .orig.tar.bz2's and compare the upstream code directly without
> needing to think about the effect of Debian changes, if I want to look
> at these in isolation.
>
> Generally though, my problems are confined to a single corner case:
> native packages using autotools.
>
> It's such a minor irritation for this specific package that I haven't
> got the need to change the package build system (the package code is
> stable), I haven't even got sufficient need to change the VCS. One day
> I'll get around to a proper solution but I am curious about whether
> others have similar problems with such packages. It probably comes down
> to a bad choice of build system, if I'm honest.
Well, I have been doing this, for a LONG time, to preserve my sanity when
working as upstream or in a native auto-tooled package:
1. No spawn from autotooling allowed in the VCS. EVER. .gitignore it
away at once. Autogenerated files inside the VCS repo are almost
always a bad idea. It was madness with CVS, it was bad mojo with
SVN, and it is certainly at least an annoyance with git.
2. Add an autogen.sh script that makes it trivial to retool everything as
needed. Keep it up-to-date.
3. I always hook the debian package to retool on package build. I have
no reason to trust whatever cruft upstream shipped, even if I happen to
be upstream at that moment in time.
It also means I will instantly notice if upstream started doing very
"unpure" things to the build system, such as directly modifying
autogenerated files, and it lets me try to contact them (or fix my ways,
if I am upstream) and contain the braindamage before it causes any Debian
victims.
4. Just deal with the annoyance in the debian clean target, but do use
make distclean, as it increases a lot the chances of automated removal
of autotool cruft. GNU really never thought of the need for autotooling
cleanups, as it does autoretool in place (and left over cruft is simply
ignored and doesn't crap the build).
5. Cheerfully ignore any purists complaining that debian/rules clean does
not restore whatever crap was there upstream.
I have so far, in what must be around 15 years of being a DD (or close to
that, anyway), never seen a SINGLE real usecase for that, either as
downstream, upstream or an user... so I don't consider it worth the
trouble or extra complexity. Note that I will change my position in this
if someone with a valid, real usecase ever complains about it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: