Date: Thu, 27 Jun 1996 21:11:28 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, nate@mt.sri.com, scott@statsci.com, current@FreeBSD.ORG Subject: Re: Building inside of /usr/src? Message-ID: <3279.835935088@time.cdrom.com> In-Reply-To: Your message of "Thu, 27 Jun 1996 20:24:12 PDT." <25306.835932252@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This was discussed when this piece of code went in. If you want to make > sure you get the "canonical" path, you need to unset PWD before calling > getcwd(). It was then (check commit-logs, probably the old cvstree) > accepted, abeit with some grumblings. It saves a LOT of time. [Finally, a reasoned argument and not an outright flame! :-)] So you're saying that: 1. It's part of the documented behavior of make (or should-have-been-documented behavior :-) that PWD should either not be set or be set to the same value that getcwd() returns when running make? 2. It's something we ourselves added and wasn't in Adam's original pmake? I don't see anything in the current commit logs but, as you say, there might be something in the old cvs tree. I'm more than willing to put it back (and it's only been gone for a few hours - sheesh :-), I just want to know if I can say "so don't do that!" to people like Micheal Reifenberger when they bang some other value into $PWD. If that's the case, I've no problem with putting it back. I'm also curious as to why you say it saves a lot of time when, in fact, it's done AFTER the call to getcwd() and merely overrides it. Wouldn't it make more sense to do it BEFORE the call to getcwd() so that the directory tree wasn't gratuitously traversed upwards? The way it was done leads me to believe that it was _not_ an optimization so much as it was an attempt to implement some strange workaround for AMD which may or may not still be relevant. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3279.835935088>