Subject: Re: hidden dependencies, Act II
To: Dr. Rene Hexel <firstname.lastname@example.org>
From: Johnny C. Lam <email@example.com>
Date: 06/13/2001 21:33:59
"Dr. Rene Hexel" <firstname.lastname@example.org> writes:
> "Johnny C. Lam" wrote:
> > I think we should be "default-deny", meaning we should be required
> > to explicitly name the libraries we wish to allow to be found.
> I agree, but I actually like the idea of using config.cache. This
> would alleviate us from coming up with our own pkgautoreconf (and
> eventually getting into the same mess we were in with pkglibtool).
> It should be rather easy to produce a "default-deny" config.cache
> using a script that just scans the GNU "configure" script and adds the
> desired "ac_cv_lib_whatever_main=no"/"ac_cv_header_whatever_h=no"
> entries to "config.cache".
I've spent some time mulling this over, and though I was initially
enthusiastic about it, I realize now that it's pretty hard to write a
script to scan a GNU configure script and write out a config.cache
file. For a rather representative example of a GNU configure script,
do a "make extract" in mail/cyrus-imapd and take a look at the
configure script. The only way I can see to get the libraries is to
do something like:
grep -- "checking for .* in -l.*" configure
That'll break on the lines that look like:
checking for yywrap in -l$ac_lib
It seem really hard to get the list of headers checked by the
configure script just by scanning it. It seems like the best way to
handle all the syntax is to create something like autoconf that
understands the autoconf macros that can redefine those macros to spit
out lines for a cache file.
So the question becomes: do we allow pkgautoconf, with a few small
changes, to be a replacement for autoconf, or do we modify pkgautoconf
in a fairly extensive way to generate a config.cache file?
Is my analysis correct, or did I miss an obvious way to write a simple
config.cache generator script?
-- Johnny C. Lam <email@example.com>
Department of Statistics, Carnegie Mellon University