Subject: Re: splitting pkgsrc.tar?
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/29/1999 15:12:53
[ On Fri, January 29, 1999 at 15:16:56 (+0100), Hubert Feyrer wrote: ]
> Subject: Re: splitting pkgsrc.tar?
> On 29 Jan 1999, Robert V. Baron wrote:
> > you need to do is create
> > net/coda5_client
> > mk as a link to /usr/pkgsrc/mk
> > This lets you build but all the packages dependencies fail.
> No - just put another path in your coda5_client Makefile as long as you
> test, and that's it. BTW, what I'm doing for testing pkgs, I create them
> in pkgsrc with a .work suffix, e.g. net/coda5_client.work. That way, it
> doesn't get clobbered by anything.
I suppose it's six of one and a half-dozen of another, but I'd like to
point out that there's also a '-m incpath' option for make....
I haven't tested this yet, but I think if the .include's were changed to
use angle bracket <...> quoting, then careful use of '-m' could make it
possible to build a package out of context, so to speak.
Perhaps to get rid of the "../.." issue there would need to be some way
to specify the search path (aka -m) in "sys.mk" (i.e. as a directive).
For example if the default "sys.mk" file had the fictional directive:
.if exists(/usr/pkgsrc/mk) && !defined(NO_PKGSRC_MK)
. INCPATH: /usr/pkgsrc/mk
then I think we'd be off to the races, so to speak, in making it easy
for developers to build packages out-of-context of /usr/pkgsrc, have
multiple /usr/pkgsrc* directories, etc.
(My proposal for the .INCPATH: directive is that it would work like
.SUFFIXES: does, and would append (or prepend?) to the path unless it
was first specified with an empty parameter, in which case it would
clear the current setting. Alternately it could be implemented as a
magic variable and thus be easy to append to, prepend to, or clear.)
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>