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

[John Spencer]

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.
>
> Agreed.
>
> > 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 config.site, these cached values can 
> be made the default for a system.  Modern autoconf searches for both 
> $prefix/share/config.site and $prefix/etc/config.site 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 config.site 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 config.site usage) that could be 
used/consumed easily (i.e. without having to manually maintain the 
cachefile).

> E.g.
>
> egrep '^ac_cv_func_select' config.cache >> /usr/local/share/config.cache
>
> and in /usr/local/share/config.site
>
> . /usr/local/share/config.cache
>
> In fact, one could take a boilerplate configure.ac, use it to create a 
> bare configure, and then use most of its config.cache to form config.site.


this is a good idea.
maybe autoconf could ship a config.site 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 config.site file.  In my experience, a config.site 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.

--JS