[cfe-dev] Using Clang 5.0.0 RC2 with MSVC dev builds
Nico Weber via cfe-dev
cfe-dev at lists.llvm.org
Wed Aug 16 11:39:04 PDT 2017
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:
>> > 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
>> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev