From owner-freebsd-current  Fri Jun 28 09:00:40 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA09933
          for current-outgoing; Fri, 28 Jun 1996 09:00:40 -0700 (PDT)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA09921
          for <current@FreeBSD.ORG>; Fri, 28 Jun 1996 09:00:35 -0700 (PDT)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id IAA14238; Fri, 28 Jun 1996 08:59:56 -0700
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199606281559.IAA14238@GndRsh.aac.dev.com>
Subject: Re: Building inside of /usr/src?
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Fri, 28 Jun 1996 08:59:56 -0700 (PDT)
Cc: nate@mt.sri.com, scott@statsci.com, current@FreeBSD.ORG
In-Reply-To: <1570.835932445@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 27, 96 08:27:25 pm"
X-Mailer: ELM [version 2.4ME+ PL11 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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
> suggest that we GUARANTEE that $PWD and getcwd() return the same
> contents?
> It's useless otherwise since you'll have different
> 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.

At least go ask Adam de Boor about the rational for the code, after all
this is ``contributed'' software, and you are making a visible functional
change to it.

> 
> > Please back out your commit... there was, and is, a good reason for doing
> > what it does.  The brokeness is in you new .mk stuff if any place.
> 
> I simply don't agree.  If the old make system had been a paragon of
> virtue and simplicity then I'd agree that changing it was bad.
> However, it wasn't and I don't think it is.
> 
> 						Jordan
> 


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD