<div dir="ltr">I believe at one point we discussed internally the idea of just having some command line flags that allow you to override the location of your bin, lib, and include directories.  The idea being to support hermetic toolchains (which is essentially what you've got).  Then we could still have all of this excessive validation to verify that it's a visual studio "installation", but if you've got something weird you can still just override it with options.<div><br></div><div>Reid, thoughts?</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 16, 2017 at 8:16 PM Stephan T. Lavavej via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[don hinton]<br>
> Don't these scripts set a bunch of environment variables, e.g., PATH, TMP, INCLUDE, LIB, and LIBPATH as well as LINK?<br>
<br>
They set PATH, INCLUDE, LIB, and LIBPATH (that's one for some #using metadata thing). TMP is unaffected. LINK is not set. (I am not an expert here, but I just checked an actual VS 2017 prompt.)<br>
<br>
You may be thinking about the CL, _CL_, LINK, and _LINK_ environment variables which can be set by the user in order to inject compiler/linker options.<br>
<br>
> If clang were to honor these variables instead of trying to reconstruct them on the fly based on some root,<br>
> be it VCINSTALLDIR or based on finding cl.exe in the PATH, you could set them to whatever you want/need.<br>
<br>
That sounds right to me. (INCLUDE and LIB seem to be honored already.)<br>
<br>
STL<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>