On 2-May-01 at 04:12, Ralf Corsepius ([EMAIL PROTECTED]) wrote:
> Alexander Mai wrote:
> >
> > On Wed, May 02, 2001 at 07:36:30AM +0200, Ralf Corsepius wrote:
> > > Rick Scott wrote:
> > > >
> > > The reason for doing so is config.caches to be considered the number
> > > one cause of problems for casual installers/users many package
> > > maintainers. They were sick of having to tell people to run "rm
> > > config.cache" first :). Not having a config.cache on the toplevel avoids
> > > this issue, but also prevents being able to pass config.caches down to
> > > subdir-configure-scripts and shareing config.caches with them.
> > >
> > > When explicitly specifying --cache-file=<CACHE_FILE> from the toplevel
> > > configure script, you should get the old behavior.
> > >
> > > BTW: This behavioral change is one of the main reasons why the upcoming
> > > version of autoconf will be called 2.50 and not 2.15 :).
> >
> > How do we this ?
> > We don't have a
> > cd foo && configure
> > statement in the script, the call is created by autoconf.
> It's AC_CONFIG_SUBDIRS which invokes the configure-scripts of
> sub-packages.
>
> If you want config.caches and for some reason have to rely on
> config.caches (which now is considered to be broken behavior), you will
I still fail to understand why it is considered broken behavior for a
sub-project to want to know how its parent was configured.... Or is there a way
other than the cache to do this. The project knows about the sub-project,
that's what AC_CONFIG_SUBDIRS is all about, how does the sub-project find out
about the project?????
> have to tell people to configure with "configure
> --cache-file=config.cache". If you don't rely on config.caches, there is
> nothing wrong with seeing --cache-file=/dev/null.
>
> Ralf
>
>
