Re: cache problem

[Ralf Wildenhues]

Hello Markus,

thanks for the reports.

* Duft Markus wrote on Thu, Oct 16, 2008 at 03:46:51PM CEST:
> > 
> > I just noticed, that when i enable a config.cache that is used by more
> > than one package is problematic, when the first on checks for the build
> > system type only, and the second for both build and host system type.
> > This is, because the host system type check uses ac_cv_build_alias,
> > which is set only if build system type (ac_cv_build) is not cached.
> > 
> > Now the first package caches the build system type, but not the host
> > system type, and the second package cannot configure, since the call to
> > config.sub misses an argument (since ac_cv_build_alias is used, which
> > is empty, since build system type was cached)...

FWIW, I'm not yet sure whether this is a valid problem.  Even if it is,
you should be able to work around it by adding AC_CANONICAL_HOST to the
toplevel configure.ac.  But anyway, before discussing validity let's try
to reproduce it:

I haven't been able to do so yet.  Here's what I tried.  Please modify
the example so that it shows the failure (maybe it only needs different
flags passed to configure?)

# in an otherwise empty directory:
cat >configure.ac <<\EOF
AC_INIT([build-alias-bug], [1])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_SUBDIRS([sub1 sub2])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
echo "SUBDIRS = sub1 sub2" > Makefile.am

mkdir sub1 sub2

cat > sub1/configure.ac <<\EOF
AC_INIT([sub1], [1])
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_BUILD
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
: >sub1/Makefile.am

cat > sub2/configure.ac <<\EOF
AC_INIT(sub2, 1)
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_HOST
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
: > sub2/Makefile.am

autoreconf -vi

./configure --host=i386-pc-freebsd --build=x86-unknown-linux-gnu
make distclean
./configure --host=i386-pc-freebsd
make distclean
./configure --build=x86-unknown-linux-gnu

# end of example

> Another cache problem is with updating the cache file. This seems rather
> unsafe for parallel builds using the same cache file. What about not
> using cat for updating, but writing into a separate file, and moving it
> over the original file (and not checking the mv return code). This way
> the worst that can happen, is that cache values are lost if two
> configure scripts try to update simultaneously - which shouldn't be too
> critical, since they are simply checked again the next time....

I recently posted a patch to do just this.  It wasn't applied, one
reason being that we didn't see a way how two configure scripts could be
running simultaneously; with AC_CONFIG_SUBDIRS at least (the GCC tree
uses a different way but uses per-configure cache files).  How do you
get two concurrent configure scripts updating the same config.cache file?

Thanks,
Ralf