There was a suggestion by Todd Vierling <tv@wasabisystems.com> that we
try to hack the AC_CHECK_LIB macro in autoconf as an alternative way
to deal with hidden dependencies.  I've something working that I've
placed at:

	http://www.stat.cmu.edu/~lamj/pkgautoconf-all.tgz

that contains:

	devel/automake/			changes to allow specifying the
		distinfo		 autoconf program used
		patches/patch-ac
	devel/gettext-m4		m4 files split out from gettext
	mk/diff				required diff to bsd.pkg.mk
	pkgtools/pkgautoconf		hacked version of autoconf

The hack is that the AC_CHECK_LIB macro is redefined so that if
--enable-check-libfoo is passed to the configure script, then the
behaviour is the same as before, but if the option isn't passed to the
configure script, then the script remembers that it couldn't find the
library, exactly as if it remembered a cached value of "no".

I've added some machinery to bsd.pkg.mk to deal with autoconf/automake
and friends by adding variables that contain the paths to the correct
programs (AUTOCONF=..., AUTOMAKE=..., etc.), and a new variable
USE_PKGAUTOCONF, that uses pkgautoconf instead of autoconf.  For an
attempt at some automation, if USE_PKGAUTOCONF is set to "auto", then
a pre-configure target is added that calls "pkgautoreconf --force
--include-deps".

To use the above packages, extract the tgz file into your pkgsrc tree
then apply to the diff to bsd.pkg.mk.  If you have automake installed,
then remove it and install a new version with the new patches.
Finally, for some GNU configured package, try adding
USE_PKGAUTOCONF=auto to the package Makefile and see what a "make
configure" will do.

I've tried converting a few packages (bison, gdbm, mutt, and lesstif)
to use pkgautoconf, and I've observed the following:

(1) Many packages patch only the configure script, or only the
    Makefile.in file.  These changes get lost when pkgautoreconf (or
    autoconf) is invoked unless the changes are propagated to the
    configure.in and Makefile.am files.  Package maintainers now must
    have some passing knowledge as to how autoconf and automake work
    in order to properly edit those files and generate patches for
    them.

(2) Interactions with automake: if automake is installed, then it's
    invoked from pkgautoreconf, otherwise pkgautoreconf/autoconf just
    ignores the fact that automake isn't there and moves on.  I can't
    see any problems right away, but I've a feeling this behaviour
    might cause some problems down the road.

(3) Packages that depend on automake seem to include an explicit
    dependency on autoconf as well, instead of relying on automake to
    include the dependency automatically.  All those explicit
    dependencies on autoconf need to be removed.

(4) You need to trawl through the autoconf input files carefully to
    find out which libraries may need to be found.  Again, package
    maintainers need to have some more knowledge about how autoconf
    works.

I'd like to get feedback on how to improve things and get this stuff
committed.  I feel that having both this method and the buildlink
method (outlined in a previous email) will solve most of our hidden
dependencies issues in pkgsrc.

	Cheers,

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