Subject: Re: mount*(8) linked as one binary ?
To: Frederick Bruckman <>
From: Chris G. Demetriou <>
List: tech-userlevel
Date: 10/27/2000 17:06:51
Frederick Bruckman <> writes:
> > Really, BSDSRCDIR is broken.  The source tree should not need to know
> > where it currently lives, in order to build with full capabilities.
> > Requiring that defeats use of NFS in many situations, makes moving
> > source trees harder, etc.
> What's the problem, really? It looks to me like just one more thing to
> set in /etc/mk.conf or on the command line.

you can't really reliably set it in /etc/mk.conf or even in
${MAKECONF}'s file if your source tree can move.  having to set
_another_ thing on the command line or in the environment you
certainly could do... but that's suboptimal.  indeed, that you even
need to set MAKECONF for many builds is quite subomtimal.

Really, in a perfect world, you'd have a mk.conf at the top of 'src'
that could control configuration parameters for a given tree -- or,
better, a mk.conf at the top of a _build tree_ into which the object
files are all put, and absolutely read-only source tree.

In the world that I live in:

* I have multiple NetBSD source/object trees, that i often 'pushd'
back and forth into and try to build in.

* even those may move from their normal locations thanks to NFS.

because of these issues, I can't really use objdirs -- they require
BSDSRCDIR to be set, and as always, the question is "which one do i
mean _right now_"?  I can live without objdirs, since they're defined
to not materially affect the build.  Rather use them, but i can cope

If your feature went in, it would affect the build, and i'd really
want to use it too.  8-)

(I run into the same problem with CVSROOTs, btw.  I regularly use N:
netbsd developers, netbsd anon, gnu sourceware general, gnu gcc,
private work, private home, and occasionally a few others...  it's got
the same issue.  You've gotta keep meta-information directly
associated with the tree, as it does with CVS/R*.)

> I tried to expand ${.CURDIR} and save it (SAVED_DIR:=${.CURDIR}), and
> use that, but it didn't seem to be doing the right thing. I'm starting
> to think there must be a reason why most projects set $TOPDIR or $SRCDIR.

I'm more of a fan of TOPDIR, or a variant of it that's more robust in
the face of only having a partal source tree if one can be found, as
long as it's relative.