Rick Scott wrote:
>
> On 1-May-01 at 17:05, Ralf Corsepius ([EMAIL PROTECTED]) wrote:
> > Alexander Mai wrote:
> > >
> > > Ok, my remaining Xlt configure problems are actually due to the call
> > > to that script. I run the following command
> > >
> > > /home/mai/compile/lesstif/lesstif/configure --prefix=/home/mai
> > > --enable-nonstandard-conversions --enable-build-21 --enable-default-21
> > > --enable-build-12 --enable-maintainer-mode --enable-build-Xlt
> --enable-build-Xbae --enable-debug --enable-tests --disable-build-20
> > >
> > > which in turn triggers this command while/after running the toplevel
> > > configure
> > > configure: running /bin/sh
> > > '/home/mai/compile/lesstif/lesstif/lib/Xlt/configure' --prefix=/home/mai
> --enable-nonstandard-conversions --enable-build-21 --enable-default-21
> --enable-build-12
> > > --enable-maintainer-mode --enable-build-Xlt --enable-build-Xbae
> > > --enable-debug --enable-tests --disable-build-20 --cache-file=/dev/null
> > > --srcdir=/home/mai/compile/lesstif/lesstif/lib/Xlt
> > > The problem is the "--cache-file=/dev/null". I'm using autoconf/CVS
> > > meanwhile, but I think I had this earlier, too. Do I have an obvious
> > > mistake in my commandline?
> > No, with autoconf/cvs, config.caches have been disabled and are
> > redirected to /dev/null instead. This becomes visible if having
> > config-subdirs.
> >
> > Note: having config.caches disabled also breaks sub-configure scripts
> > which silently have been sharing config.caches with their parent
> > configure scripts. If setting config.cache to /dev/null breaks
> > something, this in many cases indicates broken configure scripts which
> > silently try to share config.caches.
>
> This sucks!!! Why would you not share config.cache if you are sharing the
> configure command???
Well, I had expected this reaction (My initial reaction wasn't much
different, when this behavior had been introduced :).
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 :).
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
