Re: RFA/RFC: Pass --cache-file=/dev/null on to subconfigures

[Nick Clifton <nickc at redhat dot com>]

Hi Ralf,

> >   Any comments or reasons why the patch should not be applied ?
>
> Yes.  Unless you have actively changed any precious variables, they
> should not be inconsistent and the cache should not be invalidated.

Ok, first of all though, do you agree that it should be possible to 
build a toolchain without using config caches ?  Ie should a 
"--cache-file=/dev/null" specified at the top level be passed on to the 
configure scripts in sub-directories ?

Also, as an aside, what about a "--config-file=<foo>" top-level 
configure switch where <foo> is a non-absolute filename.  Eg:

  --config-file=foo.config.cache

Should a switch like this be allowed to change the name of the config 
cache files used in the sub-directories ?  Currently this will not work, 
and my patch would not fix this, but I was wondering if it was expected 
to work.

> Can you please provide me with a recipe to reproduce this

OK, here is what works for me.  Using the latest gcc and sourceware 
mainline sources, with symlinks from the gcc source directory to the 
sourceware source directory, on a Fedora 11 x86 host, in an empty 
directory, run the following commands:

  % <path-to-top-level-gcc-sources>/configure \
    --quiet \
    --target=arm-eabi \
    --enable-languages=c

  [The configure options are not essential, but they do make it faster 
to reproduce the problem.  I suspect that you need to choose a target 
that uses multilibs].

  % make all-target-newlib

  % touch <path-to-sourceware-source>/newlib/configure

  % make all-target-newlib

Result:

  configure: error: changes in the environment can compromise the build
  configure: error: run `make distclean' and/or `rm ./config.cache' and 
start over
  make[1]: *** [Makefile] Error 1


Note that the configure script at the top level of the newlib source 
directory was built with autoconf v2.59.  This is doubtless part of the 
problem.  But the issue is that if the gcc sources are part of an 
integrated source tree where some of the configure files have not been 
created with the latest version of autoconf (2.64 ?) then rebuilds of 
the toolchain can fail.

Requiring that all configure files be updated to the latest autoconf 
version might be the technically correct way to solve the problem, but 
is not really a very practical solution.  Allowing toolchains to be 
configured without config caches is a workaround, but one that is much 
simpler to adopt.

Cheers
  Nick