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.  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}.

> 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.  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.
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.

> I really do want to break the packages that are not yet using BUILDLINK
> since I'm only using binary packages on the final production machines.
> 
> I do not ever want any packages to find libraries or headers of other
> packages under $PREFIX while they're building.
> 
> I want to avoid as many of the headaches with third-party libraries as I
> can this time around, especially with the ugly shared ones.  If that
> means I have to convert packages to using BUILDLINK as I need then
> that's fine -- I'm happy to do that!  I'm only using a very tiny subset
> of all of pkgsrc anyway (about 150 or so total last time around)....

Feel free to submit more PRs on this issue.  I am actively doing
buildlink work in pkgsrc with a few other developers, and more help on
this front would certainly be appreciated.  If you intend to do so,
then please read Packages.txt, especially the sections describing the
buildlink methodology/philosophy.  I would appreciate constructive
feedback on either the "why" or the "how" of buildlinkifying pkgsrc.

> > Could you show me what you have in /etc/mk.conf that makes your pkgsrc
> > builds effectively non-standard?  It sounds like you've been working
> > on the same problem that buildlink was invented to solve, and it would
> > be beneficial to compare methods.
> 
> No, I've not been doing very much different with packages lately.  I've
> brought forward my hack on some minor stuff to resurrect and fix the
> REQUIRE files, etc., and I've got some minor tweaks to handle calling
> "make package" with "su" (just like "make install" does), as well as a
> couple of itty bitty fixes and improvements.

The tweak to call "make package" with su is a good one to submit as a
separate PR.  I would certainly welcome it.

> I'll send you my pkgsrc/mk/* diffs, and a sample mk.conf directly so
> that they don't clog up this PR.

If you could, please direct the diffs and the mk.conf file to
pkg/10680 as it's the relevant PR concerning this issue.

I will be closing this PR as the problem you reported is basically
irreproducable except on your non-standard setup where all packages
are built "(effectively) with USE_BUILDLINK_ONLY", which is not
supported within pkgsrc (yet).

	Cheers,

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