From owner-freebsd-bugs Thu Jan 10 15:12:46 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (pop-mu-8-2-dialup-24.freesurf.ch [194.230.141.24]) by hub.freebsd.org (Postfix) with ESMTP id 4945A37BCFE for ; Thu, 10 Jan 2002 15:10:10 -0800 (PST) Received: from beerswilling.netscum.dyndns.dk (dcf77-zeit.netscum.dyndns.dk [172.27.72.27] (may be forged)) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6) with ESMTP id g0AMkhO70198 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Thu, 10 Jan 2002 23:46:43 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/8.11.6) id g0AMkhn70190; Thu, 10 Jan 2002 23:46:43 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Thu, 10 Jan 2002 23:46:43 +0100 (CET) Message-Id: <200201102246.g0AMkhn70190@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery To: Sheldon Hearn Cc: freebsd-bugs@freebsd.org Subject: Re: changing MAKEOBJDIRPREFIX crashes buildworld with read-only src References: <52960.1010574001@axl.seasidesoftware.co.za> Organization: Men not wearing any pants that dont shave X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: TDC Suisse AG, Rumlang X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [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