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!?
Or did I miss something here?
--
Alexander Mai
[EMAIL PROTECTED]
