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