Subject: BSDSRCDIR, was Re: mount*(8) linked as one binary ?
To: Chris G. Demetriou <>
From: Frederick Bruckman <>
List: tech-userlevel
Date: 10/28/2000 08:50:18
On 27 Oct 2000, Chris G. Demetriou wrote:

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

That begs the question of where the top of the build tree _is_, so
you're asking to set BSDSRCDIR, or equivalent, in every Makefile in
the 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
> without.

So the objects all go on NFS? That can't be good. I believe you
presently only need to set BSDSRCDIR (and BSDOBJDIR) to _build_ the
object tree. The smarts to use "obj" as the object dir are in "make"
itself. (Excuse me, we now use the MAKEOBJDIR or MAKEOBJDIRPREFIX
environment variables.) I wonder what happens if you build an object
tree, and then build with only MAKEOBJDIR=obj set in the environment?
I guess it should mostly work, but some of the fancy release building
stuff may (or may not) break.

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

GNU Configure can easily handle relative paths, because it _creates_
all the Makefiles in the object tree, which is where you build. With
NetBSD's fixed Makefiles, and building in the source tree, it becomes
a different proposition.

It may be possible to replace BSDSRCDIR with a path relative to
${.PARSEDIR}. It doesn't have to be quite as ugly as
"BSDSRCDIR=${.PARSEDIR}/../../", but I don't see how you can avoid
putting _something_ in each Makefile ("LEVEL={1,2,3,4}", maybe).

It's an open question how the body would react to seeing the Makefiles
churned that way. On the one hand, PR misc/10338 makes a similar case
to yours, disparaging BSDSRCDIR. On the other hand, some users have to
set BSDSRCDIR anyway, to build the xsets (the lists aren't under
xsrc), or to build lkms under pkgsrc (and cross-compilers, in the future).