conan [question] improve windows clang handling in conan

trafficstars

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

[x] I've read the CONTRIBUTING guide.

Apr 04 '22 09:04 AndreyMlashkin

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.

Apr 04 '22 20:04 memsharded

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.

Apr 05 '22 07:04 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

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

Apr 05 '22 07:04 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

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

Apr 05 '22 07:04 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.

Apr 05 '22 08:04 SSE4

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

Apr 05 '22 08:04 AndreyMlashkin

I have installed clang, using 'choco install llvm'

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

Apr 05 '22 08:04 SSE4

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

Apr 05 '22 08:04 AndreyMlashkin

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

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

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

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

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

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

Apr 05 '22 08:04 SSE4

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)

Apr 05 '22 12:04 StellaSmith

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.

Apr 05 '22 12:04 SSE4

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

Apr 05 '22 13:04 StellaSmith

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)

Apr 09 '22 19:04 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.

Apr 20 '22 10:04 SSE4

@memsharded is windows-clang improvment on the roadmap?

Apr 28 '22 19:04 AndreyMlashkin

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

https://github.com/conan-io/conan/issues/1839 - a very first issue from 2017
https://github.com/conan-io/conan/issues/2285
https://github.com/conan-io/conan/issues/5896
https://github.com/conan-io/conan/issues/6927
https://github.com/conan-io/conan/issues/7868
https://github.com/conan-io/conan/issues/9295
https://github.com/conan-io/conan/issues/9505

PRs

https://github.com/conan-io/conan/pull/3574
https://github.com/conan-io/conan/pull/4253 - a first attempt to add STL setting for clang-cl
https://github.com/conan-io/conan/pull/5705 - a minor improvement for clang-cl settings
https://github.com/conan-io/conan/pull/8218
https://github.com/conan-io/conan/pull/9477

Conan Center Index

https://github.com/conan-io/conan-center-index/issues/4028
https://github.com/conan-io/conan-center-index/issues/8172
https://github.com/conan-io/conan-center-index/issues/8173
https://github.com/conan-io/conan-center-index/issues/8175
https://github.com/conan-io/conan-center-index/issues/9806
https://github.com/conan-io/conan-center-index/pull/9807
https://github.com/conan-io/conan-center-index/issues/9808
https://github.com/conan-io/conan-center-index/issues/9809
https://github.com/conan-io/conan-center-index/pull/9822
https://github.com/conan-io/conan-center-index/issues/9832
https://github.com/conan-io/conan-center-index/pull/9833
https://github.com/conan-io/conan-center-index/pull/9834
https://github.com/conan-io/conan-center-index/pull/9835
https://github.com/conan-io/conan-center-index/issues/9837
https://github.com/conan-io/conan-center-index/issues/9838
https://github.com/conan-io/conan-center-index/pull/9844
https://github.com/conan-io/conan-center-index/issues/9954
https://github.com/conan-io/conan-center-index/pull/9956
https://github.com/conan-io/conan-center-index/issues/9959
https://github.com/conan-io/conan-center-index/issues/9960
https://github.com/conan-io/conan-center-index/issues/9964
https://github.com/conan-io/conan-center-index/issues/9965
https://github.com/conan-io/conan-center-index/issues/9966
https://github.com/conan-io/conan-center-index/issues/9969
https://github.com/conan-io/conan-center-index/issues/9970
https://github.com/conan-io/conan-center-index/pull/9971
https://github.com/conan-io/conan-center-index/issues/9972
https://github.com/conan-io/conan-center-index/pull/9988
https://github.com/conan-io/conan-center-index/pull/9993
https://github.com/conan-io/conan-center-index/pull/9994
https://github.com/conan-io/conan-center-index/pull/9997
https://github.com/conan-io/conan-center-index/pull/10005
https://github.com/conan-io/conan-center-index/pull/10007
https://github.com/conan-io/conan-center-index/pull/10029
https://github.com/conan-io/conan-center-index/issues/10537

other

https://github.com/conan-io/conan-docker-tools/issues/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.

May 05 '22 08:05 SSE4

@memsharded is windows-clang improvment on the roadmap?

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

May 10 '22 07:05 SSE4

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) https://github.com/conan-io/conan/blob/db343feac208a000bc6546556104a8511a584f1e/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py#L56

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 https://github.com/conan-io/conan/blob/db343feac208a000bc6546556104a8511a584f1e/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py#L69, 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

May 24 '22 08:05 memsharded

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?

May 25 '22 05:05 SSE4

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 https://github.com/conan-io/conan/blob/db343feac208a000bc6546556104a8511a584f1e/conans/test/functional/toolchains/cmake/test_cmake_toolchain_win_clang.py#L69, 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.

May 25 '22 08:05 memsharded

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.

May 25 '22 08:05 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.

May 25 '22 08:05 memsharded

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

May 25 '22 08:05 AndreyMlashkin

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

May 25 '22 08:05 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
 
 
[email protected]_cmake
[email protected]_clang(version="12")
[email protected](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.

May 26 '22 18:05 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.

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.

May 30 '22 07:05 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.

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).

May 30 '22 07:05 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.

May 30 '22 07:05 SSE4

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

Jul 21 '22 01:07 TheClonerx

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

Jul 21 '22 01:07 TheClonerx

conan conan copied to clipboard

[question] improve windows clang handling in conan

conan
conan copied to clipboard