Subject: Re: Proposal: buildlink for X11
To: Johnny Lam <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 08/21/2001 10:39:38
On Tue, 21 Aug 2001, Johnny Lam wrote:

> On Mon, Aug 20, 2001 at 04:35:38PM -0500, Frederick Bruckman wrote:
> > On Mon, 20 Aug 2001, Johnny Lam wrote:
> >
> > > A possible solution for this is to create a shadow directory of symbolic
> > > links under ${LOCALBASE} of the true X11R6 headers and libraries in
> > > ${X11BASE}.  Call this shadow directory "${BUILDLINK_X11_DIR}".  Then
> > > if a package may be made to look for X11R6 files under ${BUILDLINK_X11_DIR},
> > > then it avoids the problem noted above, and thus may be strongly-
> > > buildlinked.
> >
> > That would really suck.
> >
> > What's the point? Whether you build with -Ishadow-tree/include or
> > -I/usr/X11R6/include, the pre-processor is going to have access to
> > everything in /usr/X11R6 either way.
> No, the pre-processor would _only_ have access to what is in the _base_ X11R6
> installation.  The distinction is important.

I'm not following you. If you use -Ishadow-tree/include, and the
shadow-tree has every include from evere package that's in the base
tree, what has that bought you?

> > More to the issue, the way I understand it, buildink is supposed to be
> > addressing a deficiency of GNU configure. "xmkf" and "imake" don't pick
> > up random things that happen to be found in /usr/X11R6/include, so what's
> > the problem?
> The fact is that the vast majority of software in pkgsrc uses GNU configure.
> Whether it's a deficiency or not that it tries to make the most featureful
> software by using everything available in the environment is debatable, but it
> is usually a concern only for software packagers that desire building the same
> package consistently regardless of what's in the environment.  But that's what
> we do in pkgsrc.

I understand that. My question is, why are you build-linking "imake"
packages, which _don't_ share GNU configure's philosophy.

Why don't you tell us exactly what problem you're trying to fix (which
packages), so we can see if there's a better way of fixing the problem
than imposing a shadow tree under ${LOCALBASE}?