autotools and patches
robert at linuxfromscratch.org
Wed Aug 30 21:40:16 PDT 2006
I'm lucky to have a job that allows me to daydream. I was thinking today, and
so here is the resulting rant :-)
I think it would be a good idea to install autoconf, automake, libtool, and
probably autogen too, in chapter 5 /tools, to allow us to autoreconf
everything in chapter 6 chroot.
First, newer autoconf add newer gcc options, like -std=gnu99 to CC. It's not a
major thing, but its nice.
Second, bugs like the ones in Gawk with LANGINFO_CODESET/LC_MESSAGES can be
fixed properly by grabbing the latest configure.ac from gawk-cvs(which
doesn't seem to actually exist, but there's a newsgroup), instead of silly
hacks to config.h. If these sorts of things are not already fixed upstream, a
configure.ac patch is likely to be accepted upstream. Bugs in m4 macros can
also be fixed globally by reconfiguring every package... Owl Linux has a
couple patches to fix warnings caused by conftest code in autotools.
Third (and best), patches to configure.ac and makefile.am are easier to
maintain and far more likely to be accepted upstream. Our
coreutils-suppress_uptime_kill_su patch is a good example. This patch needs
to be re-diffed for every Coreutils release, and it will never end. The best
way to not install these programs would be to add
a --without-program=uptime,kill,su option to configure.ac. Some Linux
distributions use some coreutils' programs and not others, so in the Linux
community there must be a dozen hacks to Coreutils to solve basically the
same problem. An autoconf/automake macro to disable the build/install of
selected programs would allow every distribution to use the same patch. It's
better for us because we would have ten times as many testers and auditors
using the same patch, its far more likely to be accepted upstream, and the
patch would not need to be re-diffed for every new Coreutils release.
Autotool patches are also generally smaller and easier for administrators to
Furthermore, as I mentioned a while ago it would be nice to have macros for
warnings, ssp, fpie, fortify_source, and even mudflap, so they have configure
switches to enable or disable them. Again these are far more likely to be
accepted upstream if they are configured with autotools, especially now that
these features are all in mainline GCC. The same way default_pic -fpic is
detected in Glibc, default_ssp can be detected and -fno-stack-protector would
be added by --disable-ssp... or -fstack-protector[-all] added
by --enable-ssp, or the default to do neither. If accepted upstream, package
maintainers (the folks who do the most debugging and auditing) would be more
likely to find/fix problems which everyone else may have overlooked.
I'm just as guilty of making hacked patches as anyone else. Its a bit more
work to add proper macros and scripts for autotools initially, but in the
long run its less work.
And the last thing I thought about today was a patch policy for HLFS. I think
it would be a good idea to make it obligatory for patches to be submitted
upstream for review. Package maintainers can either accept, modify, or reject
the patch. If it is accepted or modified, more people would be using the
patch and it would withstand more testing and review (which is better for
everyone). If the patch is rejected but still added to HLFS, we can add a url
to the mail thread in the book so there is a documented explanation.
Again, I admit I'm as guilty as anyone, but the way our patches are made needs
to change. Many of our patches are ugly hacks which have no prayer of ever
being accepted, which leaves us to maintain them indefinitely, and leaves the
Linux community to have a dozen patches to fix the same problem. I'm tired of
participating in this amateur hacking and I'd like to start taking these
things a little more seriously. I plan to patch every package to fix compiler
warnings, and I want to get off on the right foot.
To start, an --enable-werror macro could be added to the autoconf package so
its available to every package when they're reconfigured. Its a simple matter
of copying the macro to m4/ and including it in aclocal.m4 for submition to
package maintainers. The Autoconf macro archive at
http://www.gnu.org/software/ac-archive/ has lots good examples. After that,
go one package at a time fixing warnings and fixing existing unsuitable
patches. Unfortunately this will break HLFS even more than it is already, and
put the first stable release even further in the future, however it will make
the first stable release better.
I can't really see a disadvantage, other than the time consumption. Does
anyone have reasons against adding autoconf, automake, and libtool to chapter
5? I'd love to hear comments too, maybe there are issues I have overlooked.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev