[Top][All Lists]

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

Re: configure speedup proposal: add --assume-c99 and --assume-posix2008

From: John Spencer
Subject: Re: configure speedup proposal: add --assume-c99 and --assume-posix2008 flags
Date: Sun, 23 Mar 2014 20:30:07 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Bob Friesenhahn wrote:
On Sun, 23 Mar 2014, John Spencer wrote:

there are many configure scripts out there that still check for things that are standard since at least 10 years, and doing this extensively and over and over (people building software themselves usually build more than one package) consumes a lot of time (especially due to the non-parallel nature of configure scripts). often configure scripts take longer to finish than compiling the source code itself on decent machines with multiple cpu cores.


having an option like --assume-c99 could provide a shortcut so all checks

I don't like any approach which hard-codes assumptions in Autoconf. Hard-coded assumptions can easily be wrong and configure scripts could be used ten years later without being re-generated with the latest rules.

The Autoconf configuration cache mechanism (e.g. --config-cache) is very effective. In my test here, using --config-cache reduced repeated configure run time from 20 seconds to 5 seconds. By transcribing selected lines from config.cache to, these cached values can be made the default for a system. Modern autoconf searches for both $prefix/share/ and $prefix/etc/ and will use whichever ones are found.

yes, i currently use an approach that copies a custom config.cache into the builddir. however this implicates a maintenance burden, and i heard some voices criticizing that approach as to unreliable. using a in place of my manual approach is interesting and may make it look a little bit more legitimate, however it's essentially the same.

what i'm trying to achieve is that there's some kind of official upstream stategy (like currently the usage) that could be used/consumed easily (i.e. without having to manually maintain the cachefile).


egrep '^ac_cv_func_select' config.cache >> /usr/local/share/config.cache

and in /usr/local/share/

. /usr/local/share/config.cache

In fact, one could take a boilerplate, use it to create a bare configure, and then use most of its config.cache to form

this is a good idea.
maybe autoconf could ship a generator script which tests the libc capabilities in regard to c99 and posix 2008, and generates the cache for usage in a systemwide install? testing anything else like for example whether ncurses.h is installed is imo bogus, as the user could easily remove ncurses-dev from his box after having run through the .site-generator script. otoh it's unlikely that his libc implementation removes functionality that it already had. despite that, the script should definitely display a warning that it should be rerun whenever the libc was updated.

having this script available as part of autoconf would make it easily accessible to distribution maintainers, so everyone could benefit.

With this approach, Autoconf can be optimized for a system with known behavior without placing brittle assumptions within Autoconf itself.

A separate script could be used to create a reusable subset of config.cache based on a specification.

BTFW that some software might not configure correctly given the presence of a file. In my experience, a file can cause harm when configuring GCC.

i didnt experience this sort of problem with gcc, but i had some cases where the information in my handtuned config.cache was outdated and caused build failures.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]