Re: [committed] Disable shared cache file more.

[Nathanael Nerode]

Alexandre Oliva wrote:
> On Jan  5, 2004, address@hidden (Nathanael Nerode) wrote:
>
> > I'm disabling the shared cache file for the obvious reason; different
> > subdirectories want to cache different, inconsistent values for the same
> > variables.
>
> You'd better document extensively such inconsistencies such that, when
> they're addressed, we can re-enable the cache, without the risk of
> urban legends about problems long solved holding it back.
OK, I'll try.  First of all, autoconf 2.5x vs. autoconf 2.13; second, 
multilib subdirs; third, raw_cxx versus regular CXX; fourth, funny 
options for GCC bootstrap.  These are the known problems.  There may be 
other problems relating to autoconf 2.5x 'precious' variables, but 
they're lost in the noise of the above problems.  :-P

So as soon as top level bootstrap is in and all host dirs have converted 
to 2.5x, we can try reenabling the shared host cache.  And I intend to.
How shall I best document this?

As soon as top level multilibs are in, we can try reenabling the shared 
target cache, provided special provisions are made for libstdc++-v3 and 
libjava, and several other things are fiddled with.  :-P

Incidentally, it is also possible to diagnose cache file differences at 
the moment, by comparing the cache files after the build.  If anyone 
would like to help debug the problems this way, feel free.

> Anyway, naming a config.cache file for the host is wrong.  The user is
> entitled to name a config.cache they want configure to use, and it
> should be honored at the very least for host packages.
That's nice.  Unfortunately, it doesn't work at the moment.  I concluded 
that it was totally unimportant, compared with (a) getting things 
working, and (b) allowing modernization of the configure.in scripts.

(It is honored for the top level configure script, anyway, so 
technically I'm not doing anything wrong.  :-P)

I'm not terribly happy about this set of changes, but I felt that we 
needed to make progress while avoiding build regressions for 3.4.0.  If 
you have a better solution, by all means apply it; I spent quite a while 
trying to come up with one, and finally decided that there was no better 
option in the 3.4.0 time frame.