On Feb 25, 2000, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> cd foo-1.9; configure; make; make install
> login to other machine
> cd foo-1.9; configure; make; make install
> # Phew! That was easy!
> The worst thing about this scenario is that it will often silently
> appear to work, except that a few of the config variables will be
> wrong.
It won't silently work if you use the new macro
AC_VALIDATE_CACHED_SYSTEM_TUPLE, created to address this very issue.
> The newbie can rightfully expect to be politely told (by configure
> or make) "Don't do that", at the very least, instead of shooting
> himself in the foot this way.
Like:
How about ``remove config.cache and re-run configure'', as printed by
AC_VALIDATE_CACHED_SYSTEM_TUPLE?
> I'm not proposing that the config.cache feature be removed, only that
> it not be made the _default_.
Sounds reasonable to me. How about only enabling it when given the
option --cache-file=<filename>?
> Is foo() in libbar? No? Try adding -L/usr/openwin/lib to the link
> path. How about now? Maybe try -L/usr/X11R6/lib instead?
Yup, this is quite hard to implement with the feature currently
offered by autoconf :-(
The unfortunate side-effect of your proposal is that these tests would
suddenly start working, *unless* someone used a cache file. It is
autoconf that has to be extended to support this kind of test. I.e.,
the caching mechanism is not the culprit, it is the lack of an
autoconf feature that gets you in trouble.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaranį
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
