From owner-freebsd-current Fri Jun 28 04:27:48 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA26750 for current-outgoing; Fri, 28 Jun 1996 04:27:48 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA26731 for ; Fri, 28 Jun 1996 04:27:41 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA24857; Fri, 28 Jun 1996 21:24:11 +1000 Date: Fri, 28 Jun 1996 21:24:11 +1000 From: Bruce Evans Message-Id: <199606281124.VAA24857@godzilla.zeta.org.au> To: jkh@time.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: Building inside of /usr/src? Cc: current@freebsd.org, nate@mt.sri.com, scott@statsci.com Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> If you read the comments above this section of code, and have worked on >> asymetric AMD managed user home directory systems, and used pmake >> in parallel mode on these systems it would be clear as to why it if >> preferintial to use $PWD if $PWD infact resolves to the sameplace as >> getcwd(). >But PWD can't be trusted, as we've already seen. How would you I think PWD can be trusted to be NOT set except at the top level. It isn't supported by /bin/sh, and it shouldn't be exported, so for `cd $subdir; make', PWD is never set. Thus PWD is very rarely set except for developers who cd to a bottom level directory and invoke make there. Then it is convenient for ${.CURDIR} and ${.OBJDIR} to be short paths through symlinks. >invocations of the build return totally different obj directories and >the only reason this didn't become a problem before was because the >"window" for failure was narrower - you had to have a bogus $PWD at >the time you built the links rather than just at any time. I think the obj links were canonical paths because pwd was used to create them. Perhaps this is why pwd was used - ${.CURDIR} might have been non-canonical. Bruce