Date: Thu, 10 Jan 2002 23:46:43 +0100 (CET) From: BOUWSMA Beery <freebsd-user@dcf77-zeit.netscum.dyndns.dk> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: freebsd-bugs@freebsd.org Subject: Re: changing MAKEOBJDIRPREFIX crashes buildworld with read-only src Message-ID: <200201102246.g0AMkhn70190@beerswilling.netscum.dyndns.dk> References: <52960.1010574001@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
[replies sent directly to me may timeout and bounce, since I'm not
online as often as I should be, but I'll check the list archives]
What you said!
> My guess is that you have stale .depends files in your read-only source
> tree.
Thanks, but I've run the `cvsupchk' utility on my source to clean
out other leftover junk, and unless the python os.listdir fails to
catch these hidden files, I'd hope that isn't the case. A `find'
reveals nine dot.files and one dot.directory that are in the cvsup
list file...
But you've given me the kick I needed to try again and see if I can
figure out why things seem b0rken for me. And it turns out that, as
usual, it is a case of misguided boneheaded operator stupidity.
Looking more closely, it seems to be a problem before the make depend
stage, with `make obj' being the problem. Hard to pay attention when
the MAKEOBJDIRPREFIX gets longer and longer...
What seems to be happening is that I've set MAKEOBJDIRPREFIX in the
/etc/make.conf file unconditionally, and that gets read to set the
default environment settings one can see here:
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/4.5-PRERELEASE ...
But what happens in the `make obj' stage is that as part of the
share/mk/bsd.obj.mk process, the /etc/make.conf file is read again
and overrides the environment setting, restoring the bootstrap-tool
obj destination to that of a normal build, instead of the way that
it should be --
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/4.5-PRERELEASE/usr/src/i386 DESTDIR=/usr
/obj/4.5-PRERELEASE/usr/src/i386 ...
Then, in the `make depend' that immediately follows, it looks for the
object directory that didn't get created where it is looking, and falls
back to making the .depend in the read-only source directory, or trying.
If the object directory *does* exist, then it goes ahead and the full
path appears in the output, making it appear different.
Of course, I ignored the caution in the Makefile or bsd.obj.mk file,
that I've just now paid attention to, and in the /etc/make.conf file
I said
MAKEOBJDIRPREFIX = /usr/obj/4.5-RC1
As it turns out, ifI were to say
MAKEOBJDIRPREFIX ?= ...
^^
*then* the buildworld goes merrily along its way, solving this
puzzle that has bothered me for weeks. And that's what's happening
right now: finally I'm able to build each release in its very own
object directory, and not have to worry about problems that might
occur by sharing.
I know I had this problem with something else, and I had the same
problem with NetBSD, but there I was able to work around it since
one can specify a different BSDOBJDIR, from which MAKEOBJDIR or
similar is created, but which doesn't get recycled back into the
environment. (I ran into this problem again when adapting the
mergemaster script, where it makes its own MAKEOBJDIR copies of
a few things.) I didn't see any clear and obvious way by which one
can specify an object directory path in make.conf they way I want
to.
Anyway, thanks for just now giving me a kick in the butt that I
needed to look more closely and find what's going wrong. I don't
know how best to protect people from this --
* is it possible to set things up so that an absolute MKOBJDRPRFX
given in /etc/make.conf doesn't override one given in the environment
like on the commandline? I dunno...
* Protect newbies such as myself, by clarifying this in the man
page. Okay, so it's not in the man page, but there are a number of
things there which might be desirable to optionally override, and
if that can't be done by an environment variable, then it should
perhaps be made clear that the use of `?=' rather than `=' is a
good thing, to allow the value to be set otherwise. If this is
legal -- according to the source, I shouldn't be doing that which
I am, but it seems to be okay...
Anyway, hope that others can learn from my experience.
thanks!
barry bouwsma
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201102246.g0AMkhn70190>