"Dr. Rene Hexel" <rh@vip.at> writes:
> 
> "Johnny C. Lam" wrote:
> > 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.

Well, to be honest, I don't know how to modify pkgautoconf to generate
a config.cache file, despite that I suggested it.  I'm comfortable
with the rather minor changes I've currently made to autoconf to
create pkgautoconf, and I've checked with the latest autoconf release
(2.50) and the changes may easily be propogated to that release.

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.  We'll have problems will all the
packages that used autoconf <> 2.1[23] or autoconf == 2.50, or those
packages that used a hacked version of autoconf (ncurses), though
admittedly it's only a handful of packages.

	Cheers,

     -- Johnny C. Lam <lamj@stat.cmu.edu>
        Department of Statistics, Carnegie Mellon University
        http://www.stat.cmu.edu/~lamj/