Code Review Request: Simple new build system fix

David Holmes david.holmes at
Wed Mar 13 22:13:08 UTC 2013

On 13/03/2013 11:58 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> Andrew,
>> FWIW we are not tied to autoconf 2.67. There have already been a
>> number
>> of pushes using 2.68 and now 2.69 is also showing up.
> Yes, Omair was kind enough to point me to this changeset which indeed
> uses 2.68:
> It would be nice to settle on one version though, if the generated file is
> going to be checked into the repository, otherwise everyone who has a different
> version installed is going to make lots of spurious changes to that file which
> obscure the real change.

FWIW I rarely pay any attention to the actual in 
doing a review. I only look at the changes to the m4 files etc. There's 
just too much noise. Any cross-platform build issues will be readily 
detected, and it's not likely the issues would be recognizable from the 
source code.

Fixing on one version is a problem when so many different machines can 
be involved in doing the builds. I have 2.68, no matter how I tried I 
couldn't get it to use the 2.67 that I had installed privately/locally - 
so I gave up.


> FWIW, gcc also includes the configure file in its Subversion repository and a specific
> version is used to update it.
>> David
>> On 13/03/2013 10:18 PM, Andrew Hughes wrote:
>>> I've finally found time to look at the new build system (well,
>>> there seems to no longer be any choice ;)
>>> and so thought I start out with a simple fix.
>>> At the moment, if disable-zip-debug-info is not specified, the
>>> configure output is:
>>> checking if we should zip debug-info files...
>>> with no result as $enable_zip_debug_info is unset.
>>> This simple patch makes the option use the more standard
>>> AC_ARG_ENABLE form used elsewhere and will
>>> print the default ('yes') when the option is unspecified:
>>> checking if we should zip debug-info files... yes
>>> What actually took longer than the fix was updating the generated
>>> files.  We seem to have already settled
>>> on autoconf 2.67 for generating the configure script, so my initial
>>> attempt threw up a huge number of changes
>>> as the system install is 2.69.  I was able to get it down to
>>> something closer to what is expected by installing
>>> a local copy of 2.67 but it's still not perfect.  I don't know why.
>>>   I've never been a fan of including generated
>>> files for this reason.
>>> So this script also updates to see if there is an
>>> autoconf-2.67 available and use that in preference
>>> to autoconf if it is.  I also added a little debug output so we can
>>> see which autoconf is being used in
>>> If this is ok, can you please allocate it a bug ID and let me know
>>> which tree to commit it to.
>>> Thanks,

More information about the build-dev mailing list