Date: Thu, 27 Jun 1996 22:31:09 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Poul-Henning Kamp <phk@freebsd.org>, "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: <199606280431.WAA13293@rocky.mt.sri.com> In-Reply-To: <3279.835935088@time.cdrom.com> References: <25306.835932252@critter.tfs.com> <3279.835935088@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard writes:
> > 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?
Actually, this was part of getcwd() but was backed out. It was part of
make, and Keith wanted to make it part of the generic getcwd()
interface.
>From libc/gen/getcwd.c:
revision 1.4
date: 1995/02/07 05:52:57; author: davidg; state: Exp; lines: +5 -24
branches: 1.4.4;
Backed out Keith Bostic's getcwd/$PWD hack. It is causing things to break
all over the place.
----------------------------
revision 1.3
date: 1995/02/04 19:29:22; author: phk; state: Exp; lines: +24 -5
A cute hack to speed up things by Keith: if getenv("PWD") is the same
inode as ".", then just return that. I added a check so it must start with
a '/'.
Reviewed by: phk
Submitted by: bostic@cs.berkeley.edu (Keith Bostic)
----------------------------
> 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.
It's not just AMD, but any FS which uses symlinks.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606280431.WAA13293>