[cfe-dev] Using Clang 5.0.0 RC2 with MSVC dev builds

[Stephan T. Lavavej via cfe-dev]

[Zachary Turner]
> We use the toolchain to find three different things:
> 1) bin dir
>    vs 2017:
>       <root>/bin/HostX64/x86
>       <root>/bin/HostX64/x64 
>       <root>/bin/HostX86/x86
>       <root>/bin/HostX86/x64  
>    pre-2017:
>       <root>/bin
>       <root>/bin/amd64
> 2) include dir
>   <root>/include
> 3) lib dir
>   vs 2017:
>     <root>/lib/x86
>     <root>/lib/x64
>   pre-2017:
>     <root>/lib
>     <root>/lib/amd64
> It sounds like if you had a way to configure each of these 3 paths independently, everything would work?

I suspect so - as long as it were sufficiently general to avoid assuming the stuff in the middle like "HostX86" - although I think that'd be far more than I need, and more complicated to use in practice. I'm already setting up INCLUDE and LIB, and Clang seems to be using those fine (as long as the ms-compatibility-version and linker are okay). As for the binaries, I have either the x86-native or the x64-native toolset on the PATH, and that's the cl.exe whose version I want Clang to inspect, and the link.exe that I want Clang to use. (We always use x64-hosted Clang, and instruct it to target either x86 with -m32 or x64 with -m64.)

Clang 4.0 appeared to have this behavior, of trusting the PATH.

> Alternatively, is there any way you could organize your existing directory structure into this format?

That wouldn't really be possible in practice (and I'm grinding my teeth while saying that, since I'm usually the vendor hearing a customer saying that). Our dev infrastructure assumes this internal layout and changing it would be highly disruptive and time-consuming. (In principle, I agree that the internal builds should match the publicly distributed structure, argh.)

Thanks,
STL