[llvm-commits] [llvm] r136459 - /llvm/trunk/lib/Support/Unix/Path.inc

[Nick Lewycky]

On 29 July 2011 14:08, Chris Lattner <clattner at apple.com> wrote:

>   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.
>>>
>>>
>>> If it's the current directory by definition, why doesn't getcwd return
>>> it?
>>>
>>
>> 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.
>>
>>
>> What if clang is not being run by a shell?  PWD is a shell thing, not a
>> unix syscall thing.
>>
>
> 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.
>
> 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?
>
>
> I don't understand what problem you're trying to solve here.  What are you
> trying to do?
>

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).

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.

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.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110729/cad5a868/attachment.html>