On 2-May-01 at 05:00, Alexander Mai ([EMAIL PROTECTED]) wrote:
> On Wed, May 02, 2001 at 10:15:50AM +0200, Ralf Corsepius 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
> > 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
>
> Arguing about design flaws of auto* tools and libtool is a pure
> waste of time ...
>
> So we better dig out another approach.
> Isn't --enable-build-Xlt passed? Wouldn't make sense if
> building a stand-alone version of Xlt anyway!?
Not if it becomes a default.....
>
> Or did I miss something here?
>
> --
> Alexander Mai
> [EMAIL PROTECTED]
>
>
