conan
conan copied to clipboard
[question] improve windows clang handling in conan
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.
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.
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.
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
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
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.
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
I have installed clang, using 'choco install llvm'
that's probably the one from llvm.org. I installed one from Visual Studio itself.
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
might be a helpful link: https://www.msys2.org/docs/environments/
- MSYS
CLANG64
environmentclang --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
environmentclang --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
environmentclang --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
envinronmentclang --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
environmentclang --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
ori686-w64-windows-gnu
- "runtime" could be:
msvcrt.dll
,msys-2.0.dll
orucrtbase.dll
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
)
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.
Hmm, totally forgot about msys having different macros. Then yes, we totally need to differentiate these targets.
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)
@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.
@memsharded is windows-clang improvment on the roadmap?
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.
@memsharded is windows-clang improvment on the roadmap?
I think it's on roadmap now, it's got assigned 1.49 milestone.
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
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?
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.
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.
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 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
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
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.
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 mainclang
one - To add a new
compiler.backend
orcompiler.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.
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).
- Spin a new compiler called
win-clang
that contains the specifics of clang in Windows, to not pollute too much the mainclang
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
orcompiler.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.
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
and there's also llvm-mingw, which while still using mingw windows headers, it uses llvm's toolchain, libc++ plus msvcrt/ucrt