<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 9, 2014 at 2:39 PM, Ehsan Akhgari <span dir="ltr"><<a href="mailto:ehsan.akhgari@gmail.com" target="_blank">ehsan.akhgari@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="">On Wed, Jul 9, 2014 at 5:18 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Generally we want to be careful about embedding full paths into the binary.  While nobody is doing distributed builds today, in the future we want to support that.<br>
<br>
What do you think of embedding just the basename into .drectve, and adding clang's resource dir to the LIB environment variable in the build system?  That's a far less invasive change than making clang do the link step instead of link.exe, and should solve the problem.<br>


</blockquote><div><br></div></div><div>That sounds fine for my needs.  But it will break the simple case where someone does:<br><br></div><div>clang-cl -c -fsanitize=address foo.cpp<br></div><div>link foo.obj</div></div>
</div></div></blockquote><div><br></div><div>That's OK, it doesn't work today.  I think we can also solve this for many first time users in our VS integration by always adding our library resource directory to LIB.  Anything else we need to link in like the profiler library will come from there.</div>
</div></div></div>