Subject: Re: hidden dependencies, Act II
To: Johnny C. Lam <email@example.com>
From: Dr. Rene Hexel <firstname.lastname@example.org>
Date: 06/14/2001 19:17:17
"Johnny C. Lam" wrote:
> 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
I'm afraid so, yes. There seem to be tons of different ways for the
configure script to check for certain libraries or headers.
> 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.
Yes, I'd think so, too.
> 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?
While the former has the advantage that the code already exists, the
latter has the advantage that, when (this is probably not an "if" ;-)
pkgautoconf deviates from GNU autoconf, in the worst case we might miss
writing some config.cache entries. This is no worse than what we have
now, while a full autoconf replacement may, because of deviation,
suddenly stop working with new or updated packages.
> Is my analysis correct, or did I miss an obvious way to write a simple
> config.cache generator script?
Another possibility would be a two-pass "configure" procedure: in the
first pass, the GNU configure script writes its config.cache file, which
then gets modified by a script such that only
remain. This could either be done every time a package is build, or
explicitly by the package maintainer (i.e., we could distribute such a
generated config.cache with the package).