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

automake/autoconf/libtool -- convince me

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, and I don't like
being gratuitously different anyway. So this is your chance to convince
me I'm wrong.

How I handle automake and autoconf now is I try to avoid touching the
unholy mess at all if I can. But as soon as I need to modify any of the
template files (configure.ac, Makefile.am, etc), 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. I may be moving toward always doing
this, even if I don't currently touch any template files.

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 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. 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
  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.

  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.

- 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 prefer to keep my diffs as small as possible. 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.

- 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.

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. Of course we're stuck with them, but I prefer not to let them
inflict on my packages this broken autogenerated file thing, that they
drag in only for semi-obsolete reasons of portability (ie, the worry
that some unix system somewhere does not have autoconf on it) that don't
apply to Debian at all.

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. Thanks.

see shy jo

Attachment: pgpJ5TSuka2kR.pgp
Description: PGP signature

Reply to: