>>>>> "AO" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
AO> 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.
AO> It won't silently work if you use the new macro
AO> AC_VALIDATE_CACHED_SYSTEM_TUPLE, created to address this very issue.
But this is just a special case that will reduce the mismatches, but
leave the most damaging mismatches (because the most confusing and
misleading and most likely to be silent) to the end.
For example, machine A has libxpm installed, but otherwise identical
machine B does not. If you build on A, then B, you will get a link
error. If you build on B, then A, a library which is plainly
installed will be mysteriously ignored. (XEmacs actually issues a
warning if xpm support was not detected)
Also, I again ask, if system A and B are truly identical wrt to the
cache contents, why is the user running configure at all? In the
identical machines scenario, one simply does:
ftp; gunzip; tar xf;
cd foo-1.9; ./configure && make && make install
rlogin B
cd foo-1.9; make install
Of course the build tree is on NFS, installed tree is local.
>> 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.
AO> Like:
AO> How about ``remove config.cache and re-run configure'', as printed by
AO> AC_VALIDATE_CACHED_SYSTEM_TUPLE?
This macro is just adding to the layer of kludges, making autoconf
even more baroque. I must admit that its net effect will likely be
positive, except for the fact that config.cache will be that much
harder to eradicate off the face of the planet.
>> I'm not proposing that the config.cache feature be removed, only that
>> it not be made the _default_.
AO> Sounds reasonable to me. How about only enabling it when given the
AO> option --cache-file=<filename>?
Yes!!!
Well, actually...
I don't really know how a Cygnus megabuild happens, but I imagine a
tree of configure scripts, all invoked by the top level one. One can
imagine making the use of a config.cache the default for this kind of
environment by this scheme: have each configure script check the
CONFIG_CACHE_FILENAME environment variable. If the environment
variable is found, the file it names will be used as the cache file.
If the environment variable is not found, CONFIG_CACHE_FILENAME is set
to `pwd`/config.cache, and cached values are written to this file.
This way, the cache file can be used as a debugging tool, and it is
only used if there is a true recursive configure in progress.
>> 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?
AO> Yup, this is quite hard to implement with the feature currently
AO> offered by autoconf :-(
AO> The unfortunate side-effect of your proposal is that these tests would
AO> suddenly start working, *unless* someone used a cache file. It is
AO> autoconf that has to be extended to support this kind of test. I.e.,
AO> the caching mechanism is not the culprit, it is the lack of an
AO> autoconf feature that gets you in trouble.
Hmmm. Good point. Of course, my configures don't have this problem -
I'm willing to always pay the price of a lengthy configure.
My new vague proposal above would leave the config.cache used mostly
for programs that were designed to be used together. (Trivia: two
years ago, I built a deluxe distribution for the FSF. I was shocked
that standard operating procedure for this was to use the _same_
config.cache file for all configures, even from unrelated programs.
When the whole village uses the same outhouse...)
I shouldn't be admitting this, but it is possible to turn off the
caching for a specific variable by just setting a particular shell
variable. Of course, this requires reverse-engineering the source
code to autoconf. But gorilla spit is fairly translucent.
Martin
