[question] improve windows clang handling in conan

[AndreyMlashkin]

There are many ways how to use clang on windows and we need to define how to handle most of them.

Usecases are:
GNU-style, using gcc runtime and command line
compiler=clang CC=clang.exe

MSVC-style, using MSVC runtime and command line
compiler=clang CC=clang-cl.exe

MSVC toolset
compiler=Visual Studio toolset=ClangCL

The main problem is that we can't differentiate the first two cases.
The easiest solution, from my point of view, if to treat clang and clang-cl as two different compilers.
What are your thoughts?
@memsharded
@lasote
@danimtb
@jgsogo
@czoido
@SSE4
@uilianries
@madebr
@SpaceIm
@ericLemanissier
@prince-chrismc
@Croydon

• I've read the CONTRIBUTING guide.

[memsharded]

The easiest solution, from my point of view, if to treat clang and clang-cl as two different compilers.

The problem with this is that is very likely that users will start requesting immediately some kind of binary compatibility between both, because it is basically the same compiler, with different front/cli syntax. So it totally makes sense that they are considered compatible/same binaries. The same that happens with msvc. The binary will still be considered the same as long as the compiler, version, architecture, build type matches, no matter if in one case it uses CMake generating a VS solution and in other case it uses an autotools project. As long as there is no other option or setting in the model that will make them different binaries, they are the same.

We would need to understand better some things like the using gcc runtime. Which runtime is this? the cygwin one? Because Mingw can build fully native to Windows, using the Windows msvcrt.dll runtime (always the dynamic one, up to my knowledge mingw-gcc cannot link the Windows runtime statically). So far I thought that both clang and clang-cl in Windows don't use the cygwin runtime, but the Windows one.

Also, the best would be to "divide and conquer" the different scenarios, from most requested to least one, and specially focusing on the build system integrations, like CMake. So far we have tests for conan new hello/0.1 -m=cmake_lib for clang and for CLangCL toolset. Adding the other cases in the test suite would be great, knowing a bit better how they are defined for the different build systems would really help.

[SSE4]

The problem with this is that is very likely that users will start requesting immediately some kind of binary compatibility between both, because it is basically the same compiler, with different front/cli syntax.

it's true, the compiler is the same, and they should be compatible to some degree. still, it turns out there are some differences between their defaults, e.g. I got:

2d1
< #define _CPPUNWIND 1
10a10
> #define _MT 1
212a213
> #define __SSP_STRONG__ 2
338d338
< #define __cpp_exceptions 199711L

attaching the full outputs, just in case
clang -dM -E <empty-file>:
clang.txt

clang-cl -Xclang -dM /E <empty-file>:
clang_cl.txt

therefore, binaries produced by them are different in general case. I would just add compiler.driver sub-setting for now.

[AndreyMlashkin]

Where can I find this tests? I have tried locally and both clang from msvc and clang-cl from choco-llvm failed for me

conan new hello/0.1 -m=cmake_lib
build_with_clang_cl.txt
build_with_clang.txt

[SSE4]

Where can I find this tests? I have tried locally and both clang from msvc and clang-cl from choco-llvm failed for me

as I can see, there is one test: https://github.com/conan-io/conan/blob/develop/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py

[SSE4]

using gcc runtime
not an expert in this one. I have the following options in MSYS to install:

mingw32/mingw-w64-i686-clang 13.0.1-3
    C language family frontend for LLVM (mingw-w64)
mingw64/mingw-w64-x86_64-clang 13.0.1-3
    C language family frontend for LLVM (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-clang 13.0.1-3
    C language family frontend for LLVM (mingw-w64)
clang64/mingw-w64-clang-x86_64-clang 13.0.1-3 (mingw-w64-clang-x86_64-toolchain)
    C language family frontend for LLVM (mingw-w64)
msys/clang 11.0.0-4 [installed]
    C language family frontend for LLVM

it would take me a time to understand the differences betwen these installations, and how to use them, to figure out what's the runtime they are using.
what I can say is clang --version output in MSYS is:

$ clang++ --version
clang version 11.0.0 (https://github.com/msys2/MSYS2-packages ca391a3660d17cdee1e94d5afd2e72a4f750cddb)
Target: x86_64-pc-windows-msys
Thread model: posix
InstalledDir: /usr/bin

while Microsoft one (coming with Visual Studio):

clang++ --version
clang version 13.0.0
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\bin  

notice Target: x86_64-pc-windows-msys vs Target: i686-pc-windows-msvc
I probably could also dump and compare pre-defined macro between different clang installations, and compare a "runtime" via ldd or dumpbin (e.g. what's the library binary actually uses for C and C++ standard functions).
but, perhaps @StellaSmith is more familiar with these MSYS clang variants.
that I can say, we probably have to model target as well, one way or another.

[AndreyMlashkin]

I have installed clang, using 'choco install llvm'

and my version looks like:
clang++.exe -v
clang version 14.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

and clang-cl shows the same:
clang version 14.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[SSE4]

I have installed clang, using 'choco install llvm'

that's probably the one from llvm.org. I installed one from Visual Studio itself.

[AndreyMlashkin]

There is no much difference between them for me:
clang version 12.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\Llvm\x64\bin

[SSE4]

might be a helpful link: https://www.msys2.org/docs/environments/

1. MSYS CLANG64 environment
   clang --version

$ clang --version
clang version 13.0.1
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/clang64/bin

ldd <binary>

$ ldd a.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc56c90000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc56080000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc543e0000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffc54a90000)

clang++ -dM -E -x c++ /dev/null
clang64.txt

2. MSYS UCRT64 environment
   clang --version

$ clang --version
clang version 13.0.1
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/ucrt64/bin

ldd <binary>

$ ldd a.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc56c90000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc56080000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc543e0000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffc54a90000)

clang++ -dM -E -x c++ /dev/null
ucrt64.txt

3. MSYS MSYS2 environment
   clang --version

$ clang --version
clang version 11.0.0 (https://github.com/msys2/MSYS2-packages ca391a3660d17cdee1e94d5afd2e72a4f750cddb)
Target: x86_64-pc-windows-msys
Thread model: posix
InstalledDir: /usr/bin

ldd <binary>

$ ldd a.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc56c90000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc56080000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc543e0000)
        msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000)

clang++ -dM -E -x c++ /dev/null
msys2.txt

4. MSYS MINGW64 envinronment
   clang --version

$ clang++ --version
clang version 13.0.1
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/mingw64/bin

ldd <binary>

$ ldd a.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc56c90000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ffc56080000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ffc543e0000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ffc56470000)

clang++ -dM -E -x c++ /dev/null
mingw64.txt

5. MSYS MINGW32 environment
   clang --version

$ clang --version
clang version 13.0.1
Target: i686-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/mingw32/bin

ldd <binary>

$ ldd a.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffc56c90000)
        ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x77180000)
        wow64.dll => /c/Windows/System32/wow64.dll (0x7ffc54d40000)
        wow64win.dll => /c/Windows/System32/wow64win.dll (0x7ffc55120000)

clang++ -dM -E -x c++ /dev/null
mingw32.txt

summary for MSYS variants:

• target could be: x86_64-w64-windows-gnu, x86_64-pc-windows-msys or i686-w64-windows-gnu
• "runtime" could be: msvcrt.dll, msys-2.0.dll or ucrtbase.dll

[StellaSmith]

The targets x86_64-pc-windows-msys and x86_64-pc-windows-msvc are binary compatible with each other, but the first one prefers using the msys runtime
iirc target x86_64-pc-windows-gnu uses a different abi by default thus binary incompatible, this target also usually links to GCC's runtime (ie libgcc)

[SSE4]

I don't think MSYS and MSVC targets are fully compatible, as MSYS has its own sets of defines such as __CYGWIN__ and __MSYS__:
https://github.com/msys2/MSYS2-packages/blob/master/clang/0108-Add-minimal-msys-target.patch#L137-L159
(also check other patches)

and for sure GNU is diifferent from MSVC:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.h#L824-L859

I would just assume (from conan's perspective) x86_64-pc-windows-msys, x86_64-pc-windows-msvc and x86_64-pc-windows-gnu are 3 separated entities, incompatible with each other.

[StellaSmith]

Hmm, totally forgot about msys having different macros.
Then yes, we totally need to differentiate these targets.

[SSE4]

so, do we have a conclusion now? possible set of settings could look like:

• driver_mode: ["gcc", "cl"] (the command line parser mode, which may affect compatibility due to slightly different set of defaults)
• target: ["msvc", "msys", "gnu"] (the target clang was built, affects ABI and built-in definitions)
• crt: ["msvcrt", "msys", "ucrt"] (the C runtime to use, DLL to be linked for executables)

[SSE4]

@memsharded please tell us if you need anything else to make a decision. I can collect all the needed information about various clang flavours on Windows, as I have all of them installed.

[AndreyMlashkin]

@memsharded is windows-clang improvment on the roadmap?

[SSE4]

it's again getting lost in the sands of time.
here I am collecting some links to the previous discussions we had in conan about clang-cl:

issues

• Using conan with clang-cl and CMake on Windows #1839 - a very first issue from 2017
• Clang via Visual Studio results in error #2285
• Using clang-cl with libraries compiled with Visual Studio doesn't work #5896
• [bug] vcvars not called when using clang-cl #6927
• [bug] cross compiling with clang-cl #7868
• [feature] add clang support on windows #9295
• Clang with MSVC-like cross build for windows bin from ubuntu have configuration confusion #9505

PRs

• - allow vcvars for clang-cl #3574
• Feature: add msstl to the default settings for Clang on Windows (clang-cl) #4253 - a first attempt to add STL setting for clang-cl
• Feature: add settings for clang-cl (clang on Windows) #5705 - a minor improvement for clang-cl settings
• Test agains Clang for ClangCL toolset #8218
• Feature/clang #9477

Conan Center Index

• [package] zlib/1.2.11: Build error on Windows 10 using clang-cl conan-center-index#4028
• [package] pcre/8.45: Build failed with ClangCL on Visual Studio  conan-center-index#8172
• [package] expat/2.4.1: Build failed with ClangCL on Visual Studio conan-center-index#8173
• [package] bzip2/1.0.8: Build failed with ClangCL on Visual Studio conan-center-index#8175
• [package] zlib/1.2.11: can't compile with clang on windows conan-center-index#9806
• fix clang build on windows for zlib/1.2.11 conan-center-index#9807
• [package] embree3/3.13.1: can't compile with msvc-clang conan-center-index#9808
• [package] libdeflate/1.9: can't build with clang on windows conan-center-index#9809
• - [embree3] fix clang-cl by converting resource to UTF-8 conan-center-index#9822
• [package] libvpx/1.11.0: can't compile with windows-clang conan-center-index#9832
• [package] libpq/13.6: can't compile with clang on windows conan-center-index#9833
• [package] openssl/1.1.1m: can't build with windows clang conan-center-index#9834
• [package] sentry-crashpad/0.4.14: can't build with clang on windows conan-center-index#9835
• [package] libvpx/1.11.0: can't compile on windows with clang conan-center-index#9837
• [package] pkgconf/1.7.4: can't build with clang on windows conan-center-index#9838
• - [libdeflate] fix clang-cl conan-center-index#9844
• [package] libffi/3.4.2: can't build with windows clang conan-center-index#9954
• fix openssl compilation for windows clang conan-center-index#9956
• [package] libiconv/1.16: can't build with windows-clang conan-center-index#9959
• [package] libjpeg/9d: can't build with clang on windows conan-center-index#9960
• [package] vulkan-loader/1.3.204.1: can't build on windows with clang conan-center-index#9964
• [package] protobuf/3.17.1: can't build with clang on windows conan-center-index#9965
• [package] xz_utils/5.2.5: can't compile with clang on windows conan-center-index#9966
• [package] qt/6.2.4: can't compile on windows with clang conan-center-index#9969
• [package] ffmpeg/4.4: can't build on windows with clang conan-center-index#9970
• qt6: use strawberryperl on mingw and clang-cl conan-center-index#9971
• [package] libgettext/0.21: can't build with clang conan-center-index#9972
• fix windows clang compilation for ffi conan-center-index#9988
• - [libiconv] fix clang-cl conan-center-index#9993
• - [libgettext] fix clang-cl conan-center-index#9994
• - [libjpeg] fix clang-cl conan-center-index#9997
• - [protobuf] fix clang-cl conan-center-index#10005
• - [vulkan-loader] fix clang-cl conan-center-index#10007
• fix glib compilation with msvc-clang conan-center-index#10029
• [package] zlib/1.2.12: Fails to build for Windows+Ninja+clang with build_type=Debug conan-center-index#10537

other

• Windows clang compilation (non-msvc) conan-docker-tools#295

summary : there is a lot of activity around clang-cl/clang-windows over the past years. I think it proves there is a high enough interest from the community to give it more support.

[SSE4]

@memsharded is windows-clang improvment on the roadmap?

I think it's on roadmap now, it's got assigned 1.49 milestone.

[memsharded]

Resuming work on this.

Lets try to summarize current status and support, and see what pieces are missing
I will create one comment per different configuration, and if necessary to work on them, spin a new issue.

Native Windows builds: (With MinGW Makefiles or Ninja)

conan/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py

Line 56 in db343fe

def test_clang(client):

Profile (assuming clang is in the system PATH):

[settings]
os=Windows
arch=x86_64
build_type=Release
compiler=clang
compiler.version=12

Compiler:

C:\ws\LLVM\clang12\bin\clang --version
clang version 12.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\ws\LLVM\clang12\bin

This approach will work if defining CC/CXX vars pointing to the clang installation, or adding the Clang bin dir to PATH (both via [buildenv] in the profile.

If using Ninja, check

conan/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py

Line 69 in db343fe

def test_clang_cmake_ninja(client):

, it is enough to add to the profile or to the command line:

tools.cmake.cmaketoolchain:generator=Ninja

Please check the test, the approach, test it (conan new hello/0.1 -m cmake_exe can help too), and upvote/comment if this is ok or not

[SSE4]

Native Windows builds: (With MinGW Makefiles or Ninja)

if it's a native Windows build (x86_64-pc-windows-msvc), why does it need/use MinGW Makefiles? probably, in that case, most of the users don't use/have MinGW, and just use NMake as a cmake generator?

[memsharded]

if it's a native Windows build (x86_64-pc-windows-msvc), why does it need/use MinGW Makefiles? probably, in that case, most of the users don't use/have MinGW, and just use NMake as a cmake generator?

Because this is what apparently it is more popular among users, NMake usage is in general much, much lower than Makefiles or Ninja generators.

Furthermore, it doesn't work out of the box with NMake Makefiles CMake generator. If you can and would like to contribute a fix, that could be a great addition. Starting from

conan/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py

Line 69 in db343fe

def test_clang_cmake_ninja(client):

, and changing the generator from Ninja to NMake Makefiles should work, but I have tried with different versions of CMake, and it fails in different ways.

[SSE4]

Because this is what apparently it is more popular among users, NMake usage is in general much, much lower than Makefiles or Ninja generators.

that sounds suspicious. do you have any reference? because, I assume most of people just have Visual Studio + LLVM installed (or even just Visual Studio + LLVM component selected in its installer). they don't usualy have MinGW installed.
and for sure, they would prefer our recipes work out of the box for LLVM + CMake wiithout any need to install MinGW.

Furthermore, it doesn't work out of the box with NMake Makefiles CMake generator. If you can and would like to contribute a fix, that could be a great addition.

if it doesn't work out of the box, it's sad. I can take a look later today and will let you know.

[memsharded]

that sounds suspicious. do you have any reference? because, I assume most of people just have Visual Studio + LLVM installed (or even just Visual Studio + LLVM component selected in its installer). they don't usualy have MinGW installed.

Just my understanding from doing Conan support and talking to users:

• https://github.com/conan-io/conan/issues?q=is%3Aissue+MinGW
• https://github.com/conan-io/conan/issues?q=is%3Aissue+NMake

As you can see there is an order of magnitude. I know it doesn't necessarily apply to Clang in Windows, but adding "Clang" to the search, still seems more popular. My feeling is that users try to avoid NMake, as it is slightly more complex and problematic than the other alternatives.

[AndreyMlashkin]

I would say it's 'survivorship bias' to judge about popularity of tools by issues ammount.

How can I try conan from a branch? are there any instructions for it?
I would like to try new version in windwos docker with only clang from choco installed and also with only MSVC with clang package installed

[SSE4]

How can I try conan from a branch? are there any instructions for it? I would like to try new version in windwos docker with only clang from choco installed and also with only MSVC with clang package installed

git clone --branch .. + pip install -e ., or just pip install <git url> should also work

[SSE4]

that sounds suspicious. do you have any reference? because, I assume most of people just have Visual Studio + LLVM installed (or even just Visual Studio + LLVM component selected in its installer). they don't usualy have MinGW installed.

Just my understanding from doing Conan support and talking to users:

• https://github.com/conan-io/conan/issues?q=is%3Aissue+MinGW
• https://github.com/conan-io/conan/issues?q=is%3Aissue+NMake

As you can see there is an order of magnitude. I know it doesn't necessarily apply to Clang in Windows, but adding "Clang" to the search, still seems more popular. My feeling is that users try to avoid NMake, as it is slightly more complex and problematic than the other alternatives.

I suppose we're still mixing the things here...
native LLVM (the one with x86_64-pc-windows-msvc triplet) shouldn't require MinGW to use. it's used in conjunction with Visual Studio (as it uses headers/librariess from it). using it together with MinGW sounds redundant.
LLVM from MinGW (either x86_64-w64-windows-gnu or x86_64-pc-windows-msys) obviously requires MinGW. it's fine to test these flavors with MinGW generators.

nevertheless, here are my testing results. it passes with NMake Makefiles locally, but it requires some (relatively small and simple) changes:

============================= test session starts =============================
collecting ... collected 5 items / 4 deselected / 1 selected

test_cmake_toolchain_win_clang.py::test_clang_cmake_nmake 

================= 1 passed, 4 deselected, 4 warnings in 7.24s =================

diff --git a/conan/tools/microsoft/visual.py b/conan/tools/microsoft/visual.py
index d3f948ad5..06e56e067 100644
--- a/conan/tools/microsoft/visual.py
+++ b/conan/tools/microsoft/visual.py
@@ -69,7 +69,7 @@ class VCVars:
             return
 
         compiler = conanfile.settings.get_safe("compiler")
-        if compiler != "Visual Studio" and compiler != "msvc":
+        if compiler not in ["Visual Studio", "msvc", "clang"]:
             return
 
         vs_version = vs_ide_version(conanfile)
@@ -106,6 +106,9 @@ def vs_ide_version(conanfile):
             visual_version = toolset_override
         else:
             visual_version = msvc_version_to_vs_ide_version(compiler_version)
+    elif compiler == "clang":
+        # how to find it?
+        visual_version = 17
     else:
         visual_version = compiler_version
     return visual_version
@@ -217,6 +220,8 @@ def _vcvars_vers(conanfile, compiler, vs_version):
                           "v141": "14.1",
                           "v142": "14.2",
                           "v143": "14.3"}.get(toolset)
+    elif compiler == "clang":
+        return "14.3"
     else:
         assert compiler == "msvc"
         # Code similar to CMakeToolchain toolset one
diff --git a/conans/test/conftest.py b/conans/test/conftest.py
index ce8beaee2..1bf190da1 100644
--- a/conans/test/conftest.py
+++ b/conans/test/conftest.py
@@ -36,7 +36,13 @@ tools_locations = {
 
 
 tools_locations = {
-    "clang": {"disabled": True},
+    "clang": {"disabled": False,
+              "12": {
+                  "path": {
+                      'Windows': "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\Llvm\\bin"
+                  }
+              }
+              },
     'visual_studio': {"default": "15",
                       "15": {},
                       "16": {"disabled": True},
diff --git a/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py b/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py
index 28d12841f..778198a20 100644
--- a/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py
+++ b/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py
@@ -63,6 +63,17 @@ def test_clang(client):
     assert "main _MSVC_LANG2014" in client.out
 
 
+@pytest.mark.tool_cmake
+@pytest.mark.tool_clang(version="12")
+@pytest.mark.skipif(platform.system() != "Windows", reason="requires Win")
+def test_clang_cmake_nmake(client):
+    client.run('create . pkg/0.1@ -pr=clang -c tools.cmake.cmaketoolchain:generator="NMake Makefiles"')
+    assert 'cmake -G "NMake Makefiles"' in client.out
+    assert "main __clang_major__13" in client.out
+    # Check this! Clang compiler in Windows is reporting MSC_VER and MSVC_LANG!
+    assert "main _MSC_VER19" in client.out
+    assert "main _MSVC_LANG2014" in client.out
+
 @pytest.mark.tool_cmake
 @pytest.mark.tool_clang(version="12")
 @pytest.mark.skipif(platform.system() != "Windows", reason="requires Win")

I've just hard-coded some values, but in order to use it properly, we need to locate Visual Studio installation (for vcvars). a similar thing will be needed not just for CMake, but for other build systems.

in general, I am most concerned about recipes. IMO they should just work out of the box for compiler=clang on Windows. they should't require MinGW obviously. they just use CMakeToolchain and it should be able to locate a proper CMake generator, that's it.

[memsharded]

shouldn't require MinGW to use. it's used in conjunction with Visual Studio (as it uses headers/librariess from it). using it together with MinGW sounds redundant.

This isn't really true. The build system used is irrelevant, being it MinGW, Ninja or NMake, the result is the same. The usage of VS installation is hardcoded in clang itself, so the resulting binary is basically the same, in three cases, using the VS libraries.

By default, it uses latest VS 2022, but this can be changed by activating the vcvars environment that want to be used. I agree this certainly introduces a point of variability that might be better to model, use in build system integrations and track. Maybe a compiler.backend = [None, vs190, vs191, ....]? (to match the compiler versions used in the new msvc:

Alternatives:

• Spin a new compiler called win-clang that contains the specifics of clang in Windows, to not pollute too much the main clang one
• To add a new compiler.backend or compiler.msvc_version or the like, to represent this.
• The target system can be modeled by os.subsystem = msys2, mingw..., this not necessary to add to the compiler model

I am moving this to next iteration, as 1.49 is branching today or tomorrow, and this requires more time and discussion.

[SSE4]

shouldn't require MinGW to use. it's used in conjunction with Visual Studio (as it uses headers/librariess from it). using it together with MinGW sounds redundant.

the thing is MinGW is not a build system. there is a tool mingw32-make, which is essentially just a Windows port of GNU Make. should be the only one executable we actually need from MinGW.
MinGW is a port of GCC on Windows, and this one I think isn't that popular in professional environments (it's used by many hobby and OSS deveopers, that's why we get a signiificant amount of issues).

but in reality, yes, binary should be the same, regardless of the CMake generator (unless CMakeLists.txt does some checks on generator, but I hope it's a rare thing).

so I assume we can say conan 1.49 works for Native Windows builds: (With GNU Make, NMake or Ninja), and that would be a precise statement which avoid any confusion.

(saying here about MinGW introduces a lot of confusion as MinGW contains its own 5 flavors of Windows clang executables).

[SSE4]

• Spin a new compiler called win-clang that contains the specifics of clang in Windows, to not pollute too much the main clang one

not sure if I like it. it's the same clang, and not a fork like in case of apple-clang. but it might be a reasonable given the amount of tweaks it requires compare to Linux clang.

• To add a new compiler.backend or compiler.msvc_version or the like, to represent this.

yes, that might be needed. backend might not be the accurate word here, but setting itself is worth providing.

• The target system can be modeled by os.subsystem = msys2, mingw..., this not necessary to add to the compiler model

sounds a bit confusing. possible targets are:

• x86_64-w64-windows-gnu
• x86_64-pc-windows-msys
• x86_64-pc-windows-msvc

do we say mingw subsystem implies x86_64-w64-windows-gnu? IMO It might be a bit consusing for newcomers. also, it seems like subsystem is more determined by runtime rather than target. in general target controls ABI things, like sizes and alignments of types. while runtime determines which "subsystem" may run executables.

[TheClonerx]

mingw's gcc supports two thread models: win32 & posix.
while it looks like clang only supports posix when targeting x86_64-w64-windows-gnu.
clang also supports dwarf2 (-fdwarf-exceptions), sjlj (-fsjlj-exceptions) and seh ( -fseh-exceptions, default) exception styles

[TheClonerx]

and there's also llvm-mingw, which while still using mingw windows headers, it uses llvm's toolchain, libc++ plus msvcrt/ucrt

[memsharded]

This PR #11492, merged for next 1.53 contains a few changes to better support clang in Windows, mainly for the new CMakeToolchain integration, but some minor changes for others too.

There are some other pending issues about the Windows subsystems environment management, we are also trying to improve them in #12178, so if you are using Clang in some subsystem and depend on the environment, you might want to track this PR too.

Closing this issue now, but we know that there might still be some gaps, so please try to update to the new integration (this is necessary for 2.0 anyway), and report what might still be failing against this new integration. The best starting point would be the tests in https://github.com/conan-io/conan/blob/develop/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py, or using any of the predefined templates conan new hello/0.1 -m=cmake_lib|autotools_lib|msbuild_lib|meson_lib, and open a new issue. Many thanks!

[SSE4]

I think it was closed prematurely, it's still unclear how to distinguish all these clang flavors in conan. #11492 has Docs: omit, so it's not explained anywhere...

[memsharded]

Changed #11492 docs to TBD, and I am also writing a blog post about it.

[AndreyMlashkin]

Looking forward for conan 1.54!

[memsharded]

This has been released already in 1.53! it is missing docs, but we are writing a blog post and will translate to docs later too.