"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
"ac_cv_lib_whatever_main=no"/"ac_cv_header_whatever_h=no" entries
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).

  Cheers
      ,
   Rene