On Jan 5, 2004, neroden@xxxxxxxxxxxx (Nathanael Nerode) wrote: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
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.
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.
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.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.
(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.