On Thu, 29 Nov 2001, Frederick Bruckman wrote:

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

This methodology is new, but the concept of "don't litter a tree with alien
sources" is common to all software projects with which I am familiar.  If
you add something alien to a source tree, you should expect that the parent
source tree might have some twiddling control over the new, alien component.

In any case, the pkgsrc situation is resolved with a workaround, and from
this point forward, just remember "don't stick something under src that
doesn't belong there, or else expect it to be treated as part of src".

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

Installing src/tools into /usr would wreak all kinds of havoc; src/tools and
the src/{usr.bin,gnu} tools have very different audiences.  The separate
$TOOLDIR configuration ensures that the system-build toolchain is kept
*separate* from the installed toolchain.

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

Toolchain components have been updated on release branches in the past
(rpcgen comes to mind).  Release branches should be no exception to the
default rules.

It's configurable, anyway.  "USETOOLS=never" exists for this purpose.

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

DESTDIR isn't *really* relevant.  The default of USETOOLS=yes for full
source trees exists because full source trees imply updating the system
incrementally from some base point (whether a release branch or -current).

In incremental updates, only a separate toolchain pass can give us some
reasonable hope of automating the update process.  The way we've handled
UPDATING in the past has been too cumbersome and tricky to get right.

You do bring up an interesting point that I didn't think about:  it may be
useful to have the USETOOLS=yes overrideable default if DESTDIR is set,
regardless of whether a full source tree is present.  (I'll ponder this
one.)

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

Of course.  Feel free to add BSD_PKG_MK to MAKE_ENV, if you want.  I tend to
agree with mrg's assertion that mk.conf should be configured properly for
builds underneath pkgsrc.  My fears of user-visible changes are probably
unfounded anyway.

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

This isn't trivial, mind you; more than just the tools in $TOOLDIR are
needed for successful compiles.  You need -isystem arguments to provide the
proper system include paths, among other things.

However, that doesn't mean it's impossible.  pkgsrc is supposed to ensure
that packages obey $CC, $CPPFLAGS, and so forth.

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

It's reasonable for bsd.pkg.mk to include <bsd.own.mk> to get some intimate
knowledge of the installed system.  It's therefore primarily the
responsibility of bsd.pkg.mk/bsd.prefs.mk to ensure that functionality added
to the base system doesn't interfere with development of pkgsrc.  (However,
this is handled more on a case-by-case basis, such as with the INSTALL_FILE
predicament, which was worked around in <bsd.own.mk>.)

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