matthew at linuxfromscratch.org
Mon Feb 1 15:15:33 PST 2010
Bruce Dubbs wrote:
> We might also
> consider using the environment variable CONFIG_SITE to cache configure
> settings. E.g.
> export CONFIG_SITE=/home/lfs/config.site
> # /home/lfs/config.site for configure
> # Give Autoconf 2.x generated configure scripts a shared default
> # cache file for feature test results, architecture-specific.
> if test "$cache_file" = /dev/null; then
Actually, I'm not sure how safe this is. See, for example,
"The site initialization script can specify a site-wide cache file to
use, instead of the usual per-program cache. In this case, the cache
file gradually accumulates information whenever someone runs a new
configure script. (Running configure merges the new cache results with
the existing cache file.) This may cause problems, however, if the
system configuration (e.g., the installed libraries or compilers)
changes and the stale cache file is not deleted."
As we're obviously continually building more libraries throughout LFS,
I'd think there is a good chance that the cache file would be stale more
often than not.
However, if our build order is correct, then one would hope that the
first package that checks to see if a particular library, binary or
other feature is available will be configured after that dependency has
been met, and therefore the cache file will be accurate. The only place
this will fall over is when there are optional dependencies that we do
not fulfil for whatever reason. At that point, we need to inform users
of how to invalidate either that specific cached result, or remove the
entire cache file. This is obviously particularly important when going
into BLFS which has many more such dependencies, and cyclical deps too.
More information about the lfs-dev