hierarchical config.site from distros? (was: configure -C by default?)

[Ralf Wildenhues]

Even those Autoconf users who are aware of -C do not like the slowness
of configure and the amount of tests that some projects use.  Since we
still lack some ideas for an efficient parallelization, we should maybe
think about ways to speed up things for those users that build lots of
packages, once, in a fairly similar environment.  For example distro
builders.

Some random ideas gathered:

Distributions could ship with a config.site base file for the base
system which could contain information about the header files installed,
the base types, and so on.

Packages could then build upon that and add more information about
now-installed header and library files.

The default config.site file could look into a special directory and
source some or all per-package site files in there, to gather all this
information on the fly (and maybe even do some basic consistency
checking?).

One big question is whether the creation of such data could be done
automatically.  It is not likely to succeed if every package author
or distro package maintainer has to invest much more work than invoking
some script or package build hook, to do this extraction.

Of course another question is whether such data can be generated safely
at all.  For example, header file existence is pretty safe, but whether
the preprocessor actually accepts the header might even depend on
whether some third-party header file is or is not installed.  Related
question would be to just assume that, if the dependency information in
a distro package data base is correct, then these kind of issues cannot
happen behind our backs.

Autoconf could provide some kind of functionality to determine whether
some cache variable is safe to keep.

For simplicity, we probably need to limit using such site files to
configure invocations without special CC, CFLAGS etc. settings.

Comments and suggestions appreciated.

Thanks,
Ralf