From owner-freebsd-current Fri Sep 18 15:19:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA15100 for freebsd-current-outgoing; Fri, 18 Sep 1998 15:19:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA15076 for ; Fri, 18 Sep 1998 15:19:04 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id IAA18690; Sat, 19 Sep 1998 08:18:46 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199809182218.IAA18690@cimlogic.com.au> Subject: Re: 'make world' dying in sbin/atm/atm In-Reply-To: <199809182142.OAA29095@usr09.primenet.com> from Terry Lambert at "Sep 18, 98 09:42:47 pm" To: tlambert@primenet.com (Terry Lambert) Date: Sat, 19 Sep 1998 08:18:45 +1000 (EST) Cc: mystify@friley-186-113.res.iastate.edu, jb@cimlogic.com.au, phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > The better question is "why is this vine growing over the path at > ankle level". > > In other words, are there any circumstances where using "-DNOCLEAN" > would *not* cause a problem? If not, then why is it there? If so, > then why doesn't it test to see if it's there, and say something like > "turning off 'NOCLEAN' to avoid problems...". Using -DNOCLEAN would not cause a problem if the buildworld had built past the point where it has bootstrapped all the tools into the WORLDTMP tree. Until then, the use of NOCLEAN changes the bootstrapping of tools wrt NOSHARED. This is not obvious to people (other than Bruce 8-). If people delete /usr/obj/*, the clean step will delete any rogue files from the source tree that might have been created when no prior `make obj' step was performed. Take `make includes', for example. If you do this without doing a `make obj' first, you get the rpc headers generated in your source tree. Even with the clean step, it is possible for rogue files to be left in the source directory [ I think ] if make finds an obj directory to clean. I would like our build, even at a single directory level, to insist on using an obj directory and create it if it doesn't already exist. This would mean that a separate `make obj' step wouldn't be required and we'd avoid the situation where rogue files (like .depend) end up in places that are inconsistent with builds that follow (e.g. if an obj directory is subsequently created, the build still seems to find a stale .depend in the source directory, not the one in the obj directory). There are differing opinions about how all this should/could work. The changes made to support the aout-to-elf build, for instance, are a compromise. When I committed them, I knew Bruce didn't agree with the way I was trying to do things. In the absence of anyone (including Bruce) taking on that work, I had to do something. My approach was to try to avoid changing `make world' too much because that is the minimum that FreeBSD people expect. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message