On Fri, 2 Nov 2001, Christos Zoulas wrote:

: >Strike getenv("PWD") entirely, based on prior discussion with sjg.  This
: >breaks too many situations, including MAKEOBJDIR with a :C,foo,bar,
: >transform in many cases.  It's ambiguous and unreliable, as the comment
: >above that code always indicated.  In order to have reliable objdirs, they
: >need to work the same way Every Time.
: >
: >(Note that taking this out is not a performance hit; we were already doing
: >the getcwd() call first.  So the getenv("PWD") didn't increase performance.)

: You know this breaks a lot of things specially in the presence of automounted
: filesystems...

That's precisely the type of situation where using the value of
getenv("PWD") can break things horribly, from my experience.

The problem is ambiguity of value.  If using something like BSDOBJDIR
rewriting, or MAKEOBJDIR with a :C,,, transform (as is commonly done these
days), and you have to go build a subtree, all the factors like the type of
the user's shell and whether or not PWD was provided to that shell come into
play when fiddling with PWD in the environment.

If, in any of these cases, your PWD disappears, you end up with object files
in the Wrong Place, or possibly bombing because of a RO source tree.
That's why getenv("PWD") was turned off for MAKEOBJDIRPREFIX at first, but
MAKEOBJDIRPREFIX was not what caused these problems to manifest--it was the
ambiguity of whether or not PWD will be set properly in a given build
situation, regardless of make(1) configuration.

I have a feeling that you're referring to getenv("PWD") being used for other
purposes, though -- would you mind pointing out what breaks by removing
this?  I can imagine a case where a builder may want .depend files to work
on multiple systems with different automount paths, but that's still going
to be afflicted by the fragility of PWD, and would be *much* safer using an
explicit MAKEOBJDIR :C,,, translation.

I'm open to suggestions on what to do here....

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/