Todd Vierling <tv@wasabisystems.com> writes:
> 
> On Wed, 13 Jun 2001, Johnny C. Lam wrote:
> 
> : 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:
> 
> Applause.  I don't have time to look at it at this very moment, but I'll
> trust your work on this, since you've been dealing heavily with the
> dependency goop recently.  I do promise to look at this soon when my current
> overfull plate has shrunk.

Thanks!  I don't want to commit any of this until other pkgsrc people
have at least reviewed my changes, but I feel the changes to
bsd.pkg.mk are very self-contained, so there shouldn't be problems
with breaking pkgsrc builds.  There is only the question of whether
the implementation of your idea is worthy enough to commit.

> Though having autoconf and automake as build time dependencies are a tad
> annoying, I believe the ends justify the means here.  Like libtool, autoconf
> is a common build tool which can be tailored to help isolate the pkgsrc
> build environment.

Yes.  I think that at the worst, people who build from pkgsrc will
find the need perl to be installed.  I understand that having perl
installed is somewhat of a religious issue with some people, while for
others, it's a matter of not enough disk space, but that burden can be
partially aleviated by creating diffs against the original configure
script after pkgautoreconf has been run and storing them in the
patches directory as well.  I think if we do go down this road, then
we'll need a special name for all such patches, as they'll all have to
be updated whenever pkgautoconf evolves.

> : (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.
> 
> ...Which means that patches should only patch the configure.in or
> Makefile.am files instead, because the generated files will be regen'd
> automagically.

Yes, I agree.  I was only making the observation that currently many
packages don't do this, so there is a lot of cleanup work involved in
using pkgsautoconf consistently throughout the pkgsrc tree.

> : (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.
> 
> This can cause problems where Makefile.am's have to be patched, *but* so
> long as a build dependency is marked for automake, all should be fine in
> each respective pkg.
> 
> : (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.
> 
> Actually, the typical situation *should* be that nothing external is used,
> meaning only -lc and -lgcc are automatic.  The places where this can trip up
> builds are commonly-used extra libs like -lz and -lX11 ... but a careful
> watch of the "configure" phase when putting together a pkg should make that
> a no-brainer (and point out these often forgotten dependencies which are
> only in the base system on some OS's, actually an added benefit).  This is
> all Packages.txt documentation fodder.

Well, currently -lc, -lcrypt, -lm, and -lwrap are allowed to be found
automatically, as those are core NetBSD libraries.  If USE_LIBINTL is
defined, then -lintl is also allowed, and if USE_SSL is defined, then
-lcrypto and -lssl are also allowed.  On SunOS, -lnsl and -lsocket are
automatically allowed.  Also, all of the library checks defined in
/usr/pkg/share/pkgautoconf/acspecific.m4 are automatically allowed as
they're almost all system-specific libraries that contain functions
that are a part of NetBSD's core libraries.  The last bit may have
been wrong, but that's what I'm hoping others can tell me.

I see that the diff in pkgautoconf-all.tgz is a bit outdated.  I've
placed the most recent copy of my work at:

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

so if you (or anyone else reading this!) are looking to review my
changes, please grab that tarball instead.

	Cheers,

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