<div dir="ltr">We use the toolchain to find three different things:<div><br></div><div>1) bin dir</div><div> vs 2017:</div><div> <root>/bin/HostX64/x86</div><div> <root>/bin/HostX64/x64 <br></div><div> <root>/bin/HostX86/x86</div><div> <root>/bin/HostX86/x64 <br></div><div> pre-2017:</div><div> <root>/bin</div><div> <root>/bin/amd64</div><div>2) include dir</div><div> <root>/include</div><div>3) lib dir</div><div> vs 2017:</div><div> <root>/lib/x86</div><div> <root>/lib/x64</div><div> pre-2017:</div><div> <root>/lib</div><div> <root>/lib/amd64</div><div><br></div><div>It sounds like if you had a way to configure each of these 3 paths independently, everything would work? Alternatively, is there any way you could organize your existing directory structure into this format?</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 15, 2017 at 3:17 PM Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</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>
> Unfortunately, it looks like the current test is based on the path. Perhaps<br>
> it would be better to actually run a simple test compile, a la, configure/cmake,<br>
> and spit out the value of _MSC_VER instead.<br>
<br>
My usage scenario involves running over 4,000 invocations of clang-cl.exe (one for each of libc++'s many small tests). Having each of those launch cl.exe would be highly undesirable.<br>
<br>
As I understand it, if you can find cl.exe (which you can, it's right there on the path), you can get its version information from GetFileVersionInfoW() like Reid said, without invoking it. The issue seems to be the additional directory structure analysis to find the "root path" (is this to find where the libraries are?), which I believe is causing the cl.exe to be rejected as "not a tool chain".<br>
<br>
I am continuing to set up my VM and should have a repro soon.<br>
<br>
Thanks,<br>
STL<br>
<br>
</blockquote></div>