From owner-freebsd-current Thu Jun 27 16:41:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA07448 for current-outgoing; Thu, 27 Jun 1996 16:41:04 -0700 (PDT) Received: from main.statsci.com ([198.145.127.110]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA07443 for ; Thu, 27 Jun 1996 16:41:00 -0700 (PDT) Received: from statsci.com by main.statsci.com with smtp (Smail3.1.29.1 #3) id m0uZQfT-0005zuC; Thu, 27 Jun 96 16:40 PDT Message-Id: To: "Jordan K. Hubbard" cc: Nate Williams , current@FreeBSD.org Subject: Re: Building inside of /usr/src? References: <7235.835914709@time.cdrom.com> In-reply-to: Your message of "Thu, 27 Jun 1996 15:31:49 -0700." <7235.835914709@time.cdrom.com> Reply-to: scott@statsci.com Date: Thu, 27 Jun 1996 16:40:11 -0700 From: Scott Blachowicz Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > The only thing I can figure out was that someone found AMD's path > mangling to be non-intuitive (though functional) or something and > figured they'd substitite in the value of $PWD. I can think of no > other reason for it It is extra information which, if valid, gives an idea of how the user of the makefile views the world/file systems around. Chances are that, if an automounter is used and $PWD does indeed point to the current directory, that $PWD represents the "normal" way to get to the current directory. If there are other parallel directories controlled via the same amd mountpoint, that can be useful information since the directories are mounted into a different hierarchy. How's this one sound, for example...say I have an amd-controlled mount point called "/sw" with some entries like this: src -sublink:=src \ host!=server1;rhost:=server1;rfs:=/export \ host==server1;type:=link;fs:=/export bin -sublink:=bin.${arch} \ host!=server1;rhost:=server1;rfs:=/export \ host==server1;type:=link;fs:=/export lib -sublink:=lib \ host!=server1;rhost:=server1;rfs:=/export \ host==server1;type:=link;fs:=/export #...etc... If I cd to /sw/src and do a make, the top level make sets a ${SRCDIR} variable to the current directory, then sets ${BINDIR}, ${LIBDIR} variables based on that directory. Going into ${LIBDIR} would fall over if it is set to /a/server1/sw/lib (since it might not be there if amd hasn't mounted it there yet), but not if it set to /sw/lib...or something like that. Yes, I know that's not a good behavior to rely on and if it is diagnosed could be worked around by saying 'make SRCDIR=/sw/src' and the author of the make files could probably robustify them a bit, but it behavioral change introduced by the current change to the make program. I don't know how long that particular bit of logic has been in there (for people to get used to/rely on) and who put it there (what were the reasons and benefits). So, I don't have enough info to gauge its importance, but it IS a change from current behavior that could (possibly) be avoided by just grabbing /bin/pwd output directly (or introducing a different C code path that is explicitly invoked by these makefiles). I'm not familiar with bmake files, their usage in *BSD 'make world's, etc... Scott Blachowicz Ph: 206/283-8802x240 Mathsoft (Data Analysis Products Div) 1700 Westlake Ave N #500 scott@statsci.com Seattle, WA USA 98109 Scott.Blachowicz@seaslug.org