Re: configure -C by default?

[Ralf Corsepius]

On 02/07/2011 12:39 PM, Peter Rosin wrote:
> Den 2011-02-07 11:12 skrev Ralf Corsepius:
> > On 02/07/2011 10:02 AM, Peter Rosin wrote:
> > > Den 2011-02-07 09:14 skrev Ralf Corsepius:
> > > > Provided how HW has developed since the discussions from 10 years
> > > > ago, you cited about, I am actually leaning towards proposing the
> > > > converse of your proposal: Autoconf toconsider to abandoning
> > > > config.cache.
> > > No, it still needs to be optional.
> > I don't have anything against this. However, it's simply that the
> > overwhelming majority of current packages hasn't been developed
> > with config.caches in mind. And of those which really use it
> > (complex packages such as GCC or GDB) occasionally to get things
> > wrong. So, IMO, the advantage you believe to see on cygwin or mingw
> > is of limited benefit.
> What do you mean by "believe to see" and "of limited benefit"?
When you apply config.caches across packages, there is no guarantee that 
the values stored in a config.cache have the same semantics/meaning.

I.e. when  trying to share config.caches between packages (esp. 
independently developed ones),
* you are at risk of _silently_ miscompiling something.
* not to gain much, because a configure-script doesn't not honor 
config.caches (Pretty typical for "modern" configure script using 
non-standard macros).

These were the aspects I was referring to.

> You are apparently not getting it, or you are downplaying my use case
> deliberately.
Neither - I am using autoconf for many, many years and am well aware 
about the benefits config.cache can have, when _carefully_ being used.

However, in contemporary development on todays, I've rare experienced 
config-caches to be more of a nuissance but to be of real advantage.

>   The advantage I see for the packages I care about and
> regularly work on is very real: the experience moves from the "pain in
> the ass" category to "bearable" when I enable the cache.
>
> I'm not talking about one-time builds on Cygwin, I talking about doing
> development there.
Well, I would not want to use Cygwin ;)

Ralf