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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
