On Oct 20, 2011, at 4:14 PM, Nick Lewycky wrote:
> On 20 October 2011 16:00, Devang Patel <[email protected]> wrote:
> What about following approach...
>
> I don't like it because we've been nearly successful avoiding things which
> would diverge a Google-build of clang from an open-source build of clang. Is
> there no way we can get this functionality without an ifdef? Is there a
> reason you don't like adding a flag?
Essentially, what you're looking for to say is, "on this platform use pwd".
Have you considered an alternative to use configure check to enable use of PWD ?
I want you to exhaust all alternatives before deciding to add a command line
flag. Adding a command line flag is usually easy way out, but removing an
command line flag is almost impossible.
If you add a compiler option then would it be confusing or useful to people on
other platforms?
If you still think command line flag is the way to go then pick a name that
obvious to someone who does not know what is DWARF. Something like
-fcurrent-working-dir=... or as such.
-
Devang
>
> Nick
>
>
> Index: Support/Unix/Path.inc
> ===================================================================
> --- Support/Unix/Path.inc (revision 141912)
> +++ Support/Unix/Path.inc (working copy)
> @@ -251,6 +251,9 @@
>
> Path
> Path::GetCurrentDirectory() {
> +#if defined(__GOOGLES_SYMLINKED_BUILD_ENV__) || defined(__NEED_TO_USE_PWD__)
> + return Path(getenv("PWD"))
> +#endif
> char pathname[MAXPATHLEN];
> if (!getcwd(pathname, MAXPATHLEN)) {
> assert(false && "Could not query current working directory.");
>
> ?
>
> -
> Devang
> On Oct 20, 2011, at 3:53 PM, Nick Lewycky wrote:
>
>> [+cfe-commits now that this has a patch.]
>>
>> On 20 October 2011 14:59, Nick Lewycky <[email protected]> wrote:
>> On 20 October 2011 14:55, Chandler Carruth <[email protected]> wrote:
>> On Thu, Oct 20, 2011 at 2:03 PM, Nick Lewycky <[email protected]> wrote:
>> To understand why, you first need to know that we run builds on hermetic
>> build machines.
>>
>> I'm not really sure why our build system is relevant here.
>>
>> Only because there are ways to fix that problem which would still break
>> caching in our build system. I wanted to steer us away from that.
>>
>> This has been a problem for me many times using very mundane and ordinary
>> build systems. If I build on machine X and then copy the binary to machine
>> Y, it can't find the source code if it is stored in a different directory,
>> even if the directory structure is entirely compatible.
>>
>> Why can't we follow GCC's lead here, and use PWD (when on a system with such
>> a concept) as the basis for DW_AT_comp_dir? I think what I'm missing is why
>> doing that causes problems...
>>
>> Works for me. I just want agreement for what to do (flag, using PWD,
>> whatever). I honestly don't care how it works as long as it works. I can
>> propose a patch using PWD if you want, the plumbing through -cc1 will be the
>> same either way.
>>
>> Ok, here's a patch that passes PWD through from the driver into the .bc, and
>> it comes out in the .o files. Yay!
>>
>> Please review!
>>
>> Nick
>>
>> Nick
>>
>> Chris's objections (which seem reasonable) are to *always* using PWD. To be
>> clear, I'm not suggesting that. I'm suggesting that the Clang driver, which
>> is already quite aware of the user's shell, can inspect PWD and getcwd and
>> consult any other oracle needed to determine a valid working directory, and
>> then pass it via an internal-only flag to the CC1 layer IFF it differs from
>> getcwd.
>>
>>
>> <dwarf-comp-dir-1.patch>
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
