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

[Zachary Turner via cfe-dev]

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?  Alternatively, is there any way you
could organize your existing directory structure into this format?

On Tue, Aug 15, 2017 at 3:17 PM Stephan T. Lavavej <
stl at exchange.microsoft.com> wrote:

> [don hinton]
> > Unfortunately, it looks like the current test is based on the path.
> Perhaps
> > it would be better to actually run a simple test compile, a la,
> configure/cmake,
> > and spit out the value of _MSC_VER instead.
>
> 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.
>
> 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".
>
> I am continuing to set up my VM and should have a repro soon.
>
> Thanks,
> STL
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170815/14f6f5f4/attachment.html>