On Thu, 29 Nov 2001, Robert Elz wrote:

> I have been doing this since forever, no BSD build tree has ever broken
> it, nor should it now.   The Makefile that goes in /usr/src defines what
> gets built by the standard build procedure, always has (well, there was
> a time there was no Makefile at that level, but that's ages ago now), and
> still does.   Anything else in /usr/src (including my /usr/src/local and
> other stuff I stick there) gets built in its own way.

>   | This is not an articfact of the new toolchain -- it's just something that
>   | people have lucked out on in the past.

You have to admit, that walking up the directory tree to look for
"build.sh" is something new -- it's a creative solution to the problem
of detecting the top of "src", granted -- but it is new.

> There has never been any luck about it, the build system has always quite
> carefully gone only where it is supposed to go, and interfered nowhere else.

How about, the top-level Makefile builds and installs a whole toolchain
in place (after updating "tools", and using "tools" to build it), only
if DESTDIR is not set?  Then, the bulk of the build, as well as any
single directory builds, can use the installed toolchain (if DESTDIR is
not set). For the "DESTDIR not set" case, this would build the compiler
one more time than it probably needs to be, but on the other hand, it
would lift the temptation/necessity to do the whole build twice.

Folks who are tracking the release branch and updating their systems
selectively would get the effect they're accustomed to (i.e. no
"tools"). Only builds from the top-level would get the full treatment.

Anyone doing a cross-build, or anyone who didn't want his installed
system messed up, would necessarily have to have DESTDIR set, so he'd
always build with "tools", just as now.

> The only reason pkgsrc is having a problem (and the reason that I didn't
> expect that xsrc would, which has been confirmed, and that I know my local
> stuff doesn't), is that pkgsrc is digging into the regular BSD src build
> mechanisms.

Not "pkgsrc", so much as certain packages. My suggestion, coupled with
passing BSD_PKG_MK into the package build, would just work for you, as
the "/etc/mk.conf" you posted would not, then, attempt to set DESTDIR in
"pkgsrc". If you try to set DESTDIR in "pkgsrc", you're on your own.
Actually, it would be kind of neat if "pkgsrc" could guarantee that the
"tools" directory would be used for all packages, (perhaps conditionally
on DESTDIR set plus some other knob), as "pkgsrc" could then more easily
support foreign systems and very old systems.

> Since pkgsrc these days works on non-BSD based systems, that
> don't have all this stuff, perhaps it should be made to work just the same
> way on NetBSD, and totally ignore the regular system build environment
> (that is, /usr/share/mk/*) and rely entirely upon its own make setup.
> (Sharing /etc/mk.conf can probably be handled without too much pain).

I suggested that recently, too, but Al talked me out of it. "bsd.own.mk"
has a lot of stuff that relates to the system you have installed, and
"pkgsrc/mk" and many individual packages count on it being correct, so
when a port switches to ELF, or evolves the capacity to use shared
libraries, it wouldn't be enough to simply pull up the change from
"bsd.own.mk" in current -- you'd have to have tests, as "pkgsrc" must
support the older systems, too.

Frederick