Bill Wendling wrote: > If there's a problem with old stuff being in the cache, then that stuff > probably doesn't belong in the cache. > > For our users, they rerun configure to add different options. The generic > checks (for libraries, header files, sizeof types, etc) shouldn't need to > be rerun.
They shouldn't need to be re-checked only if the configure script is, as you say, being re-run just to add different options. However, if they are re-installing after a system reconfiguration, or simply copied the entire build directory over to another machine (or use NFS) (not as uncommon as you'd think), then *every* test result is suspect. And an end-user has absolutely no clue what the config.cache file is and will have no idea why her configure failed. The most common problem I've seen is that the user runs configure, it fails because some library is missing, so the user installs the library and re-runs configure...and then it still fails, because the library check was cached. The primary purpose of the configure script is to make installation succeed for end-users, and there should be nothing in it that interferes with that goal. Period. Speed optimizations are nice, but not at the expense of having some user's configure fail inexplicably. Steven
