Subject: Re: dilema with use of LDFLAGS=-L${LOCALBASE}/lib vs. private
To: Greg A. Woods <woods@weird.com>
From: Greywolf <greywolf@starwolf.com>
List: tech-pkg
Date: 10/20/1999 20:19:17
On Mon, 18 Oct 1999, Greg A. Woods wrote:

# I think in both cases I didn't need any libraries from any other package
# and I was able to simply tromp on the value of LDFLAGS from bsd.pkg.mk
# via the following hack:
# 
# +   .if !defined(NO_USE_LOCALBASE_LIBS)
#     LDFLAGS+=		-Wl,-R${LOCALBASE}/lib -L${LOCALBASE}/lib
# +   .endif
# and then setting "NO_USE_LOCALBASE_LIBS" in the package Makefile.

Greg is inadvertantly bringing up a very good point here -- it's inadvertant
in that it's probably not the one he was trying to illustrate:

These "special cases" seem to me to be appearing more and more in the
pkgsrc tree; this isn't the first time I've seen an exception fly by.
There was XPKGWEDGE, and there was one other which I forget, and now
there's this.

Is there no other way to handle something like this?  Could it not
be handled in a more generic way, or are we relegated to add hack
after hack as more packages appear?  For instance, is autoconf creating
some of these problems?  is there a way to detect if something has been
autoconfd, or to detect a requirement on autoconf (the answer to the
latter is "yes", while the answer to the former is undetermined).

Really, I mean no offense in my question, and I will hope that none is
taken, but it's a question begging for an answer.  If we keep having to
special case things like this, I can see bsd.pkg.mk getting very large,
and becoming fraught with hackeries which may include co-dependencies
on other hackeries.

				--*greywolf;
--
NetBSD: Professional power!