Subject: Re: pkg/13649: print/gv needs updating for "buildlink.mk"
To: Johnny C. Lam <lamj@stat.cmu.edu>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 08/12/2001 21:12:18
[ On Wednesday, August 8, 2001 at 01:29:36 (-0400), Johnny C. Lam wrote: ]
> Subject: Re: pkg/13649: print/gv needs updating for "buildlink.mk" 
>
> woods@weird.com (Greg A. Woods) writes:
> > 
> > [ On Tuesday, August 7, 2001 at 18:47:55 (-0400), Johnny C. Lam wrote: ]
> > > Subject: Re: pkg/13649: print/gv needs updating for "buildlink.mk" 
> > >
> > > That doesn't sound right and would point to a bug in xpkgwedge, no in
> > > print/gv.  Since gv uses imake to generate its Makefile, there is
> > > something wrong with the Makefile generation caused by xpkgwedge's
> > > presence.
> > 
> > In fact I don't want xpkgwedge to affect where a package finds
> > *third-party* packages -- only where the package itself installs!
> > Anything more would be wrong!
> 
> You are perhaps mistaken about how xpkgwedge works.

No, I don't think so...

>  The whole (rather
> small) hack hinges on proper support within the distributed X11 config
> files for "X11ProjectRoot".  What xpkgwedge does is redefine
> ProjectRoot to ${PREFIX} and set X11ProjectRoot to ${X11BASE} so that
> a package that uses imake will look for headers and libraries in both
> ${PREFIX} and ${X11BASE} and install the package into ${PREFIX}.  This
> is instead of looking for headers and libraries only in ${X11BASE} and
> installing into ${X11BASE}.

This seems very wrong, at least in the presence of BUILDLINK support.  I
may not have invented the concept, but I certainly do understand it!

When BUILDLINK is being used xpkgwedge must only affect where packages
are installed, and MUST NOT affect where headers and libraries are found
(as normal for any X11 code only $X11BASE should be used in addition to
the normal system directories -- all third-party stuff must be handled
by BUILDLINK files).

> > If it does any more then it is broken and will cause the same breakages
> > that buildlink.mk files are supposed to avoid.  It makes no sense
> > whatsoever to use BUILDLINK only on non-imake packages since that'll
> > leave imake-using packages with the problems now eliminated in packages
> > using BUILDLINK!
> 
> xpkgwedge has nothing to do with buildlink; they solve orthogonal
> problems.

Indeed -- that's what I'm trying to say too!  ;-)

>  Packages that use imake and need to be buildlinkified
> depend on pkgtools/buildlink-x11, which inserts files into the imake
> config directory to cause the proper -I and -L switches to be passed
> to the compiler instead of -I${PREFIX}/include and -L${PREFIX}/lib.

That sounds OK to me.

> There is an analyzed PR (pkg/13638) which notes a bug in
> pkgtools/buildlink-x11 but I don't believe that is what is causing
> your problem.

Indeed my problem is that print/gv hasn't yet been modified to work with
BUILDLINK, but it needs a third-party package that has been modified to
work with BUILDLINK.

This PR supplies a very simple little patch that fixes my problem.  I
don't see anything complicated about it.  It seems clear as day what it
does and as obvious as could possibly be why it's needed.

In addition don't see why my suggested patch would break anything for
people not using xpkgwedge either -- it should be transparent to them.

Alternately maybe it should be done this way (I don't full understand
the details of all the XAW_TYPE possibilities):

Index: Makefile
===================================================================
RCS file: /cvs/master/m-NetBSD/main/pkgsrc/print/gv/Makefile,v
retrieving revision 1.27
diff -c -r1.27 Makefile
*** Makefile    2001/02/17 17:51:44     1.27
--- Makefile    2001/08/13 01:11:52
***************
*** 20,25 ****
--- 20,26 ----
  XAW_TYPE?=    3d
  .if (${XAW_TYPE} == standard)
  DEPENDS+=     Xaw3d-1.5:../../x11/Xaw3d
+ .include "../../x11/Xaw3d/buildlink.mk"
  .endif
  
  post-extract:

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>