autotools and patches

Alex Merry alexander.merry at
Thu Aug 31 02:00:45 PDT 2006

On Thu, Aug 31, 2006 at 12:40:16AM -0400, Robert Connolly wrote:
> First, newer autoconf add newer gcc options, like -std=gnu99 to CC. It's not a 
> major thing, but its nice.

I'm not sure what you mean here... how does autoreconfing allow you to
change the gcc options you can pass? Surely you can already do that in
the CC env?

> Third (and best), patches to and are easier to 
> maintain and far more likely to be accepted upstream. Our 

Definitely A Good Thing (TM).

> 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 Some Linux 

I believe that the coreutils maintainers even hinted that such a fix
_would_ be accepted upstream. Although I may have misread that, and it
may have been a random person on the coreutils mailing list...

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

Although you'd obviously want to wait until the whole system can be
built with non-hackish patches before implementing such a policy... but
in the long run I think this is a good idea. We can give back to the
FOSS community much more this way.

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

Do you mean you want to submit such a macro upstream to autoconf?

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

The only possibly issue I can think of is configure.{ac,in}
compatibility. I'm no expert on this by any means, but I had a hazy idea
that you could get incompatible versions, and this was why various
distributions installed several versions of autoconf and automake

Alex :-)

Computer Monkey to the Pelican,,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list