"Johnny C. Lam" wrote:

> > 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.

  Okay, my mistake then, sorry.  I was under the impression that the
buildlink make files already use the pkgautoconf tools you proposed some
time age and that this was the reason for using autoconf.  But this
appears not to be the case here ...

> 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

  This is why I (and several others) prefer using the original configure
script instead of generating a new one 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.

  Seconded.  Since this is not the first time the GNU build tools
underwent backwards-incompatible changes ("pkglibtool" springs to my
mind), that's definitely the safest way to handle things.

  Cheers
      ,
   Rene