Anyone who has had to build a program from source on a *nix operating system has probably encountered something like this:

checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking build system type... powerpc- apple-darwin7.5.0

This "checking" stage of the configuration process usually involves around one hundred various tests of the system, determining what commands are available to use and other environmental conditions.

It seems that almost everything goes through this phase, which seems very redundant - especially if you have to re- configure many times during troubleshooting.

So, why not have a cache of all of the various tests and such, quickly accessible by any configuration script. You could of course update the cache at any time, or tell a specific configuration script to ignore the cache and determine values for itself.
-- rgovostes, Oct 11 2004

"Hello World!" example for autoconf and automake http://www.amath.wa...lsmanual.html#SEC33
These are some of the tools that generate ./configure.in, which generates ./configure, which generates Makefile, which generates the executable. [jutta, Oct 11 2004]

In general, what you're calling for is a good thing. While installing something new, it should be easy to change parameters, and the system should quickly, and meaningfully, react to those changes.

The "./configure" script that ships with much modern Unix software (and which is responsible for the lines you qoute) already caches its configuration (in a file config.cache). It shouldn't be too hard to extend the notion to a global configuration default file shared between different tools.

I can see two problems:

One, this is already a very complicated system, with generators generated by generators etc. It is almost impossible to debug if something goes wrong in the late build phase. So, adding another layer of caching here may make something that already is ridiculously complicated just a little worse.

Two, the meaning of these tests isn't *quite* fixed. There's a large set of defaults that are pretty much the same in practice, but they can change across different versions of autoconf, and tools can add their own tests. And of course two tools, developed by two people who don't talk to each other, can use the same test with different meanings. One could work around that by explicitly distinguishing the shared from the individual variables, but as the set of shared variables evolves, there's always going to be a boundary area where meanings do change.
-- jutta, Oct 11 2004


Good point. :\
-- rgovostes, Oct 12 2004



random, halfbakery