Nick Hudson <skrll@netbsd.org> writes:
> 
> "Dr. Rene Hexel" wrote:
> 
> >   For buildlink reasons (I believe), we use our own autoconf to generate
> > a new configure script from "configure.in".  This configure script
> > suddenly requires "ltconfig" again to configure libtool and utterly
> > fails, because there is no such beast.
> 
> Johnny, Is this true?

No, we patch the configure.in file because we change some of the tests
and those are the changes that software authors actually take back
into their source trees as the configure script is a generated file.
We've been doing that since the early days of pkgsrc.  Of course, this
runs into problems only now that the fundamental GNU build tools
(automake, autoconf, libtool) are undergoing changes.  We will have to
add autoconf-2.50 to pkgsrc fairly soon, hopefully as a package that
won't conflict with autoconf-2.13.

> >   An alternative to updating our autoconf would be to use the original
> > configure script provided by the (imlib or whatever) software.  I may be
> > mistaken, but I was under the impression that buildlink was the reason
> > we used to generate our own configure script from "configure.in".
> 
> This is a much safer, i.e. future proof, thing to do anyway. Patches to
> configure.in should be added to a pkg *only* with the resulting patch to
> configure, IMO.

Given the current conditions with the GNU build tools undergoing
updates and backward-incompatible changes, we should probably only
keep patches to the configure script in pkgsrc, but continue to feed
patches to configure.in back to the software author.  This does cause
a lot of pain in certain packages that make extensive changes to
Makefile.am files, e.g. x11/lesstif.  However, this would fix those
problems in various other packages (chat/xchat comes to mind) where
touching configure.in causes automake to automatically be run, which
isn't what we want.

	Cheers,

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