Subject: Re: hidden dependencies, Act II
To: Dr. Rene Hexel <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 06/15/2001 10:19:53
On Thu, 14 Jun 2001, Dr. Rene Hexel wrote:
: That's okay. The point is that all these ac_cv_* then are present in
: config.cache and can easily be set to "no" by a post-processing script.
And then you have to re-run all the "config.status" scripts, and/or run all
the configure scripts again (hoping that all the cached values will be
honored). Prone to error.
: > There is the larger problem of the version of autoconf used by the
: > author to generate the configure script not matching the version of
: > autoconf we use, which is why the author always include the generated
: > configure script with the sources.
: Yes, that's actually what I meant when I talked about deviation ;-|
Shouldn't be a problem in >95% of cases: autoconf is mostly backwards
compatible, and will typically improve a configure script with each autoconf
: Something else that came to my mind regarding our default-deny
: tactics: we have to be very careful about what we deny the configure
: script to find. Otherwise we can easily break a package for different
: operating systems. For example, a package configured under Solaris oder
: Linux might need to find a completely different set of header files
: and/or libraries than under NetBSD.
That's even more important, and again, very deliberate. We *want* the
configure system not to find anything, on any platform, unless it's
explicitly specified. Only the known libraries available in base installs
on the current OS should be allowed.
Note that the pkgautoreconf is meant to trip up only AC_CHECK_LIB, not
AC_CHECK_HEADER. Checking headers should be fine, as a desired symbol in a
header will only get used if one of the detected libraries contains it.
(Programs that assume a symbol can be used based only on header presence are
already broken, and should be fixed with diffs back to the maintainer.)
-- Todd Vierling (email@example.com)