[ On Saturday, February 26, 2000 at 23:28:50 (-0800), Tom Tromey wrote: ]
> Subject: Re: config.cache considered harmful
>
> Greg> In fact I would go so far as to suggest that "config.cache" is
> Greg> only truly safe in its current form when it is used for nested
> Greg> configure scripts, and then only when the nested scripts are all
> Greg> directly realted in heritage to each other.
>
> If by "heritage" you mean its direct ancestry, then I disagree.
No, I just mean that they were either directly written by the same
author or were assembled and tweaked by someone who knew each fairly
intimately.
> In my experience you can mix relatively diverse configure scripts with few
> bugs. I've only run into one problem along these lines in the Cygnus
> tree in five years. (Yes, our sample is skewed. Still, it isn't that
> hard to recognize these bugs for what they are.)
I think your sample fits the bill of having a common heritage.
I am thinking more of packages such that include random other diverse
packages, usually for convenience sake.
I've seen a large number of autoconf-using packages that play all sorts
of games with autoconf internals. Then there's the amazing variety of
autoconf versions that might be assumed by such scripts and yet be in
use simultaneously too. No guarantees of correctness can be made with
the any current or prior autoconf system when you start mixing this
amount of diversity in an ad hoc fashion.
> Greg> Until version information (including much more platform details
> Greg> than just what config.guess reveals) is included in the cache
> Greg> file, and carefully checked by every consumer, "config.cache"
> Greg> shouldn't even be allowed to be turned on.
>
> I disagree. We should always assume that expert users know what they
> are doing. If I say --cache=file=foo, then I want configure to
> listen. Requiring extra hoops is bogus.
Yes, but you're assuming things are working "right". At the moment
that's not a safe assumption to make -- it's in fact impossible to
guarantee in any way since there's no attempt at all being made to
ensure the validity of the cached information.
> Greg> Even when version information is included in "config.cache" I
> Greg> think that "autoconf" should remove it unconditionally, as
> Greg> should any makefile rule which is about to run "configure" but
> Greg> detects that the script is newer than the cache file.
>
> This would be painful in my daily programming practice. I don't mind
> disabling the cache by default. But if it is enabled, I want it to
> continue to work as it does now.
Unless you've got something much smarter than "make" in mind, there's
just no way for you to represent the true internal depencencies that
would allow what you safely use cache information.
Now I don't want to say that experts shouldn't be given enough rope, but
I also don't think the rope should be carefully formed into a noose so
that un-suspecting novices don't have to learn to tie it either.
My more extreme proposal is only intended for the short term -- i.e. up
to the point where autoconf-generated configure scripts have the ability
to do better validtation of the cache information before using it.
> Anyway, autoconf usually doesn't
> know where my config.cache might be found. Only configure does.
Hmm.... good point. I guess that means it's ever more important that
the right kinds of "version" information be included in the config.cache
file and that configure scripts be always careful to check for the
appropriate compatability of such cache information before trusting it.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
