On 2-May-01 at 01:32, Ralf Corsepius ([EMAIL PROTECTED]) wrote:
> 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.
So you are saying that the default cache file will become /dev/null?? So we
won't even have a cache file in the toplevel?? So, how will we be able to get
the results of an upper level configure??? I say keep the cache file, just rm
it at the beginning if you want.
>
> 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
>
>
