Re: automake/autoconf/libtool -- convince me
On Tue, 2003-06-10 at 14:09, Joey Hess wrote:
> I find myself going off in a rather different direction from most people
> in Debian in how I maintain my packages that use automake and autoconf.
> This is distressing since one of us must be wrong,
I wouldn't say that really. Each approach has advantages and
disadvantages.
> and I don't like
> being gratuitously different anyway. So this is your chance to convince
> me I'm wrong.
That being said, I do think the way I do things is better ;)
> How I handle automake and autoconf now is I try to avoid touching the
> unholy mess at all if I can.
Yeah.
> But as soon as I need to modify any of the
> template files (configure.ac, Makefile.am, etc),
Fundamentally, if you're doing this, you're hacking the upstream source,
and that likely means your changes should really be going upstream. If
you're needing to change paths or something in the Makefile.am, that
signifies that it should be a ./configure option, for example.
> I switch the package
> over to build-depend on the tools, run them at build time, and clean up
> all generated files at clean time.
My personal approach is to never Build-Depend on the autotools, and make
my upstreams use AM_MAINTAINER_MODE. Then, when I want to patch the
upstream Makefile.am, I copy the old one to Makefile.am.old, and the
current Makefile.in to Makefile.in.old, hack the .am, run automake, then
get diffs between both the .am{.old,} and .in{.old,}, and stick those in
debian/patches. By using AM_MAINTAINER_MODE I'm assured that patching
these files won't cause timestamp issues.
> I may be moving towards always doing this, even if I don't currently
> touch any template files.
Now *this* is evil. You're going to be making your builds a lot less
predictable and reliable for no good reason.
> A lot of people have said this is wrong, but I have never heard a
> convincing argument with real examples of why this is wrong.
I wouldn't say your approach is wrong inherently, so much as the changes
should be going upstream.
> I do have
> some IMHO good reasons for doing it this way:
>
> - I want my packages to be as useful as possible to users. This includes
> letting users modify the template files if they need to and build the
> package, and have the build succeed.
I dunno. I personally would never use the Debian packages of something
as a starting point for hacking the upstream source. People shouldn't
expect it to work in general.
> Given the rapid pace of change of
> automake, I can see this easily not happening, if I have a package
> that only works with automake n, and version n is dropped from debian.
> The user would then be stuck trying to update it to the current
> automake.
Now that different versions of automake are parallel-installable (except
the bastard child 1.5), I think we'll be able to keep all of them around
for as long as they're useful.
> This is eqivilant in my mind to a package that ships with
> pre-processed C code, and compiles that. That's "ok", until you have
> to modify the real source code and header files have changed. Crazy.
Not quite; trying to compile pre-processed C code on a bunch of
different architectures is not likely to work. On the other hand
Makefile.in should work everywhere.
> Instead, the right way to do things is to run it through the
> preprocessor every time, and deal with it when it breaks. At least
> you'll know then when it's broken so you can fix it.
Yes; but on the other hand some of the breakage could just be spurious.
So it just wastes your time.
> - I refuse to manually patch autogenerated files. Many of the other
> strategies for maintaining packages that use automake seem to end up
> in requiring this sometimes.
I think the method of patching I outlined above solves this issue.
> - I prefer to keep my diffs as small as possible.
Yeah.
> I expect users and
> upstream authors to read these diffs, and if they're huge the
> important changes will be lost in the noise. I don't want to give
> upstream authors the impression that I am forking or making huge
> changes to their packages. I see 140k compressed diffs if autotools
> are run in the tree once, vs 8k diffs if they're run every build
> time and cleaned up after.
Again my method of patching will *tend* to produce smaller patches, but
they can be big if your upstream is using a significantly older version
of say automake1.4.
> - This entirely avoids the problems of lurking rules in generated Makefiles
> that decide to wake up on m68k and unexpectedly run the autotools
> (which are not present, or fail) because of stupid timestamp issues.
> Yes, I know about AM_MAINTAINER_MODE, but see above points about diffs
> and autogenerated files.
I think this is solved, too.
> While I don't know a great deal about all the portability issues the
> autotools face (and indeed, don't even know much at all about automake
> and libtool internals), I mainly only care about packages that work in a
> single distribution. And I happen to have a lot of experience with build
> systems (debhelper) that are tuned for only one distribution, and I have
> some strong opinions about the right way such a build system should
> work. Transparency is utterly important, so is simplicity, and
> consistency, and other encies. The autotools in my opinion fail on all
> counts.
They fail on those counts mainly because of the portability. Yeah, it
sucks, but as you say we are stuck with them.
> I've seen many statements from people who presumably know the autotools
> cold that what I'm doing is flat out wrong, but they never back them up.
> So if you want to convince me please keep my reasons in mind and back up
> your statements with real explanations.
I wouldn't claim to know the autotools cold; but I personally don't
think your approach to dealing with modifying Makefile.am/configure.ac
is flat out wrong or anything. What I *would* say is flat out wrong is
to be rerunning autoconf/automake even if you're *not* modifying
configure.ac/Makefile.am.
My approach above gives more predictable builds, but it is less
transparent and more of a pain. I think I like keeping it painful
because it reminds me I should be sending the stuff upstream :)
Reply to: