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/