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

[Ralf Wildenhues]

* Nick Clifton wrote on Fri, Sep 25, 2009 at 04:50:06PM CEST:
> >>  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 ?

Please do commit it, since I guess it is necessary in practice.
However, this necessity is always a sign of a bug in the GCC/src
build system.

> 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.

Well, with upstream Autoconf, you only ever have one cache file anyway,
so it works there.  GCC/src could easily let such a switch cause the
use of different cache file names in the sub-directories.  I'm not sure
what the benefit would be, though.

> >Can you please provide me with a recipe to reproduce this
> 
> OK, here is what works for me.

Thanks.  I will investigate it.  A couple of notes:

[...]
>   % 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

There should be more information in the error message, namely the
variable(s) that changed and how they changed.  This information
can be helpful to find the bug.

> Note that the configure script at the top level of the newlib source
> directory was built with autoconf v2.59.

That is not a problem *per se*: a couple of caching bugs were fixed in
2.60, and 2.62, respectively, but the toplevel config/override.m4 file
has overrides for these fixes that *should* work for any released
Autoconf between 2.59 and current.  The only crucial bit is that
override.m4 is used for creating newlib/configure (and all other
configure scripts, for that matter).  If aclocal is used, then adding
'-I ../config' or similar to its flags (ACLOCAL_AMFLAGS) should be
sufficient, otherwise adding sinclude([../config/override.m4]) early in
configure.ac (before AC_INIT) works.

The current newlib uses confsubdir.m4 which fixes one of the problems,
but not the other.

* Charles Wilson wrote on Fri, Sep 25, 2009 at 04:48:56PM CEST:
> I've seen it happen -- building gdb/insight which is part of the src
> tree if not gcc specfically -- when a precious variable contained a
> leading space.

This is probably one of the bugs fixed by override.m4, and the insight
part is one that the autotools update hasn't touched.

Cheers,
Ralf