Subject: Re: Toolchain Update (27-Nov-2001)
To: NetBSD Toolchain Technical Discussion List <tech-toolchain@NetBSD.ORG>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-toolchain
Date: 11/29/2001 16:09:08
On Thu, 29 Nov 2001, Greg A. Woods wrote:

: I think if we simply also turn off the USETOOLS part of the "src" magic
: ".ifdef BSD_PKG_MK"

Actually, this was worked around by setting USETOOLS=no in
pkgsrc/mk/bsd.prefs.mk.  It's not the responsibility of <bsd.own.mk> to deal
for this unusual filesystem layout.

: BTW, why not use the already defined BSDSRCDIR instead of searching for
: it in the magic _SRC_TOP_ way?

Because a large number of users do not set BSDSRCDIR properly, or use it at
all.  (The only place where BSDSRCDIR is actually *used* by the build
system, aside from being a fallback for _SRC_TOP_, is for the
BSDSRCDIR/BSDOBJDIR obj rewrites in <bsd.obj.mk>.  These rules aren't used
by everyone.)

: extremely non-descript file named 'build.sh' (and a similarly
: non-descript directory named 'tools')

This will be made much more robust and easy to identify, as I've already
stated earlier in the thread.

: > "pkgsrc" does not live one level below "src" -- it lives at the same
: > directory level.  It is not meant to be mergeable with "src".
:
: I hope you meant "at the same conceptual level" -- literally pkgsrc
: should be usable anywhere and any number of instances should co-exist.

Correct.  "pkgsrc" is not, in particular, a child of "src", and ideally, it
shouldn't be.

: I'm beginning to think /etc/mk.conf should only be used for things in
: <sys.mk> and that all <bsd.*.mk> stuff should look first for a mk.conf
: file in ${BSDSRCDIR} just like pkgsrc now uses a relative
: 'bsd.pkg.defaults.mk' file.

mk.conf isn't used by <sys.mk> at all.  It's only used by things which
include <bsd.own.mk>.

: > Source trees are set up to contain a specific set of subcomponents.  The
: > parent package's maintainer has no responsibility (in most cases, no
: > *ability*) to know that you put extra alien sources in its tree; it's up to
: > you to deal with changes in the parent's build structure which affect you.
:
: Hmmm...  If you alter the parent hierarchy's build system to trigger a
: build in the "alien" directory then that's true, otherwise it really
: shouldn't be....

As I said in a part you didn't quote:

: > If you're leveraging the build structure of "src" (<bsd.*.mk>) inside
: > "src", you should fully expect your alien tree to behave as if it were
: > building with "src".

And, since pkgsrc was pulling in <bsd.own.mk>, it was rightfully bound to
the rules set by the "src" tree when residing inside "src".

However, this has been worked around already.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/