[community triplet] adds triplets for building with clang/LLVM for Windows

[walbourn]

This adds ten (10) new community triplets for building with the clang/LLVM for Windows toolset which is an optional component available in Visual Studio. While MSVC and clang/LLVM for Windows are in general link compatible, some developers would prefer to avoid relying on the MSVC compiler.

These four triplets are for building Windows platform targets:

arm64-clangcl-dynamic
arm64-clangcl-static
x64-clangcl-dynamic
x64-clangcl-static

These four triplets are for building Xbox platform targets:

x64-clangcl-scarlett-static
x64-clangcl-scarlett
x64-clangcl-xboxone-static
x64-clangcl-xboxone

These two triplets are for building UWP platform targets:

x64-clangcl-uwp
arm64-clangcl-uwp

Note that clang-cl does not support the (now deprecated) C++/CX language extensions (/ZW, /FU, /AI, /WINMD). This toolset is fully supported by the new C++/WinRT language projections.

These triplets should also improve the conformance testing for libraries in VCPKG.

[Neumann-A]

#29034 (comment)

(try building python3 with these triplets)

[walbourn]

(try building python3 with these triplets)

I'm currently building ALL ports with the x64-clangcl-dynamic triplet. I'll post the results back when its done.

[Neumann-A]

#25897

waiting for #28773 and #27694

[walbourn]

#25897

waiting for #28773 and #27694

My proposal here is to only support clang/LLVM for Windows using the MSVC-like clang-cl.exe front end. The numerous patches you have applied in that PR look like they are for using clang.exe directly which is not as well supported a scenario from the Visual Studio experience.

The 'pure LLVM' implementation looks a lot more complicated. Why all the overrides when CMake already supports this scenario pretty well?

[Neumann-A]

My proposal here is to only support clang/LLVM for Windows using the MSVC-like clang-cl.exe front end.

The true home of that triplet is https://github.com/Neumann-A/my-vcpkg-triplets/blob/master/x64-win-llvm.cmake

The numerous patches you have applied in that PR

No that is clang-cl and most of the patches have been merged. (as said i am waiting for two prs to be merged before updating that PR.)

Why all the overrides when CMake already supports this scenario pretty well?

The problem are library authors not correctly supporting it. Checking e.g. CMAKE_<LANG>_COMPILER_ID for msvc or clang and not thinking about clang-cl.

[walbourn]

Trying 2130 ports, 1445 successfully built without changes using the new x64-clangcl-dynamic triplet. I'll look into the 685 failures more tomorrow (although about a 100 of them fail because they don't support windows).

[walbourn]

Looking into the failures, there's a few cases here:

• Obvious conformance issues as found by @Neumann-A in their testing work.
• Upstream CMakes that failed to check for "MSVC-Like" when using Clang
• Reliance on 'over-inclusion' in headers in some cases that can be fixed with additional header includes.
• For boost, there's an issue where CMAKE_AR is being used without quotes when invoked which fails because the llvm-lib tool path is under `C:\Program Files``.

[walbourn]

The boost failures are due to a 'b2' bug filed here.

[walbourn]

About 290 of the 685 port failures are directly related to the boost problem which is a bug in b2 build.

With the additional changes from code review, I'm able to build 30 additional ports out of the 685.

[walbourn]

Tried another full pass of all current ports with the latest version of the triplet.

1424 out of 2194 ports build ok. That leaves 770 failures (with ~100 being non-Windows ports).

21 additional ports will build with a workaround for the 'spaces in path name' for the CMAKE_AR library tool variable. There's no good way to do this directly in the vcpkg toolchains at the moment, so I'm leaving this workaround out for now. Hopefully we can get it fixed directly in b2, or we can find a robust way to do GetShortPathName with CMake directly in future.

[walbourn]

Draft documentation microsoft/vcpkg-docs#76

[abique]

So much work here, it is impressive!
Good luck with everything 👍

[walbourn]

After merging the latest changes, the try-compile tests for these new triplets pass:

.\vcpkg.exe install try-compile:arm64-clangcl-dynamic --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:arm64-clangcl-static --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:x64-clangcl-dynamic --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:x64-clangcl-static --overlay-ports scripts\test_ports --enforce-port-checks

.\vcpkg.exe install try-compile:x64-clangcl-scarlett-static --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:x64-clangcl-scarlett --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:x64-clangcl-xboxone-static --overlay-ports scripts\test_ports --enforce-port-checks
.\vcpkg.exe install try-compile:x64-clangcl-xboxone --overlay-ports scripts\test_ports --enforce-port-checks

 .\vcpkg.exe install try-compile:arm64-clangcl-uwp --overlay-ports scripts\test_ports --enforce-port-checks
 .\vcpkg.exe install try-compile:x64-clangcl-uwp --overlay-ports scripts\test_ports --enforce-port-checks