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

[Nico Weber via cfe-dev]

On Wed, Aug 16, 2017 at 2:30 PM, Reid Kleckner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, Aug 16, 2017 at 11:21 AM, Stephan T. Lavavej <
> stl at exchange.microsoft.com> wrote:
>
>> [STL]
>> > Here's how to repro my directory structure in a clean VM.
>>
>> [don hinton]
>> > Currently, for pre-2017, the root directory must be in the form <some
>> path>/VC.
>>
>> Note that these development builds (both my actual ones, and the repro
>> constructed from the nuget package) are 2017-class. They just don't conform
>> to 2017's normal installer.
>>
>> > Could you try renaming x86ret and amd64ret to VC and try it again? e.g.:
>> > C:\Temp\binaries\x86ret\bin\i386       ==> C:\Temp\binaries\VC\bin\i386
>> > C:\Temp\binaries\amd64ret\bin\amd64    ==> C:\Temp\binaries\VC\bin\a
>> md64
>>
>> Sure. x86 still misbehaves, but x64 works properly! Does this indicate
>> that Clang just needs to do slightly less strict validation of the root
>> directory (possibly controlled by an option)?
>>
>
> I'm in favor of this. If we find a cl.exe on PATH, we can take its version
> and use that to set our compatibility mode flags. We don't need to validate
> that it looks like its in a VC installation tree, and I'd rather not have
> an option for it. Whatever we use the knowledge of the VC tree root for
> would probably not work though. We won't be able to find and prefer the
> x64/x86 cross-linker, for example.
>

Isn't "cl.exe on path" the common case for people running vcvarsall?
Wouldn't we want to validate in that case? (If not, why do it ever?)


>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170816/57486895/attachment.html>