<div class="gmail_quote">On 29 July 2011 14:08, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word"><div class="im"><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">

<div><div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

Reverted in r136477. I honestly don't see how it's any more or less correct than using getcwd, since $PWD is the current directory per definition.</div></span></blockquote><div><br>





</div></div><div>If it's the current directory by definition, why doesn't getcwd return it?</div></div></div></blockquote><div><br></div><div>POSIX specs that the value returned by getcwd may not contain symbolic links. PWD may contain symbolic links because of how it's required to be set by "cd". In either case it needs to be the current directory, but they can be different strings.</div>



</div></blockquote><br></div></div></div><div>What if clang is not being run by a shell?  PWD is a shell thing, not a unix syscall thing.</div></div></blockquote><div><br></div><div>Mm, you're right. I misremembered PWD as being a required environment variable across all process invocations, but it's only defined in the shell execution environment, which applies only to things run by the shell. The answer is that if PWD were unset it would fall back to getcwd. Of course, PWD could also be just plain wrong if not invoked by a shell.</div>



<div><br></div><div>I didn't really want to have two get current directory methods in Support, and I don't think I want to hard-code "PWD" in clang. Does getShellCurrentDirectory in Support sound reasonable?</div>



</div></blockquote><br></div></div><div>I don't understand what problem you're trying to solve here.  What are you trying to do?</div></div></blockquote><div><br></div><div>We're trying to fix the DW_AT_comp_dir value, which doesn't agree with what GCC does. It would make sense to bury it in the gcc-compatibility layer, or maybe even gate whether we look at $PWD on the presence of -no-canonical-prefixes (though GCC doesn't).</div>

<div><br></div><div>We run our compiler in a symlink heavy environment. All the file contents are in /cas/[md5sum] files, and the working directory contains nothing but a forest of symlinks to them. That means that even the clang binary itself is a symlink, and getcwd returns the name with the [md5sum] in it.</div>

<div><br></div><div>Before running the compiler, we clobber PWD to set it to something sensible -- and more importantly, something repeatable across builds. If the output contains clang's md5sum, a change to clang would trigger a relink of everything, even if the only change to the .o was the comp_dir value itself. We'd like to avoid that.</div>

<div><br></div><div>Nick</div><div><br></div></div>