Re: cache directory is not removed

[Bill Wendling]

Also sprach Steven G. Johnson:
} 
} 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.
} 
At this point, I direct said user to the "make distclean" command, but,
yes, I do run across these problems on occaision.

} 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.
}
Even in this compelling situation there are options. For instance, on a
configure failure, don't cache the result (or don't cache results for
libraries checked through the AC_CHECK_LIB command). Add information to
the cache about what machine you're running on (gotten from
config.guess). If this changes, the cache is ignored. Etc. None of which
are too difficult to implement, one would think.

-- 
|| Bill Wendling                        address@hidden
|| Coding Simian