Subject: Re: hidden dependencies, Act II
To: Dr. Rene Hexel <rh@vip.at>
From: Johnny C. Lam <lamj@stat.cmu.edu>
List: tech-pkg
Date: 06/15/2001 04:54:57
"Dr. Rene Hexel" <rh@vip.at> writes:
> 
> "Johnny C. Lam" wrote:
> 
> > No, I think you missed my point.  The config.cache generated depends
> > on what's already been found during the configure process.  The
> > resulting config.cache file won't contain all of the ac_cv_* values
> > possible.  For an example, see pkgsrc/graphics/magicpoint.
> 
>   Sigh.  It would have been too easy, wouldn't it? ;-)
> 
>   Something else that came to my mind regarding our default-deny
> tactics: we have to be very careful about what we deny the configure
> script to find.  Otherwise we can easily break a package for different
> operating systems.  For example, a package configured under Solaris oder
> Linux might need to find a completely different set of header files
> and/or libraries than under NetBSD.  In the worst case, this might even
> apply to different ports/versions of NetBSD as well.

I think this is desired behaviour according to the default-deny
philosophy, or at least the way Todd envisioned it and thus the way I
implemented it.  The libraries you're probably thinking of are system
libraries, e.g. -lnsl -lsocket on Solaris.  These are already
explicitly allowed under the pkgautoconf paradigm if you take a look
at the changes that I proposed.  In my opinion, I think libraries in
the base system should be automatically allowed to be probed by
configure scripts, so I've placed a small OS-specific section in
bsd.pkg.mk where I added system libs of which I knew.  The case of
different versions of NetBSD having different headers and libraries
(such as for readline or curses or openssl) is better handled by the
buildlink stuff, which is orthogonal to the pkgautoconf stuff.

	Cheers,

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