(0028890)
Brad King (manager)
2012-03-12 09:10

The Modules/Platform/Windows-GNU-(C|CXX|Fortran).cmake files contain the Windows-specific (MinGW) rules for the GNU compiler. Similar files will need to be written for Clang, called Modules/Platform/Windows-Clang-(C|CXX).cmake.

(0028910)
rubenvb (reporter)
2012-03-13 16:12

OK, adding Windows-Clang-[C|CXX].cmake files that are pure copies does the trick for MinGW related Clang.

Before I submit a patch, I'd like for the MSVC-built Clang to work as well. Is there any pre-existing example I can check out to read "clang --version" output and parse it to differentiate?

Thanks!

(0028911)
Brad King (manager)
2012-03-13 16:22

If we were to support only the MinGW version, then since Clang strives to be command-line compatible with GCC rather than copies perhaps just include the GNU ones:

# Platform/Windows-Clang-C.cmake
include(Platform/Windows-GNU-C)

This is already done for "Compiler/Clang-(C|CXX).cmake". The situation is more complicated if we want to support MSVC-style Clang too.

Does the MSVC-built Clang try to be command-line compatible with MSVC?

Does MinGW-style Clang define __GNUC__?
Does MSVC-style Clang define _MSC_VER?

If the answer to the above three questions is "yes" then we probably need to distinguish the two compilers with separate compiler ids. Instead of just "Clang" we may need to use "ClangMS" and "ClangGNU" or something like that. Alternatively we would need to introduce the notion of a secondary id.

This problem already partially exists for the Intel compiler except that it is always GNU-style on Linux and MSVC-style on Windows so we can distinguish them by separating Platform/Windows-Intel-* and Platform/Linux-Intel-*.

(0029558)
Brad King (manager)
2012-05-24 13:11

(0029560)
rubenvb (reporter)
2012-05-24 14:16

The proposal in the mailing list discussion would work, except for the fact that Clang does not have a cl-compatible driver right now. They still plan to have one someday, but don't expect that to happen anytime soon.

The only thing differentiating the two Clang versions is the "binutils" part, which should be eg. link.exe for the MSVC one and ar.exe for the MinGW one. I noticed the CMake variables are wildly different in the two cases.

So there needs to be some way to pull in the GNU compiler options along with the MSVC tool options. I don't know if this kind of splitting is already present.

Also: perhaps an "if" on CMAKE_GENERATOR being "MinGW Makefiles" or "MSYS Makefiles" vs everything else (ie MSVC) is better than the platform id, maybe not. I don't know.

(0029561)
Brad King (manager)
2012-05-24 14:25

Re 0013035:0029560: The platform id is computed from the toolchain in use so we know what the compiler targets. I think it is the right thing to use. I hadn't thought of it when I wrote 0013035:0028911.

Do the platform files proposed in that thread:

$ cat Platform/Windows-Clang-C.cmake
if("${CMAKE_C_PLATFORM_ID}" MATCHES "MinGW")
   include(Platform/Windows-GNU-C)
else()
   include(Platform/Windows-cl)
endif()

$ cat Platform/Windows-Clang-CXX.cmake
if("${CMAKE_CXX_PLATFORM_ID}" MATCHES "MinGW")
   include(Platform/Windows-GNU-CXX)
else()
   include(Platform/Windows-cl)
endif()

work for you?

(0029562)
rubenvb (reporter)
2012-05-24 14:28

For MinGW: yes, perfectly.

For MSVC: no: it tries to locate GNU binutils which aren't what MSVC-built Clang uses. It relies on MSVS link.exe and friends.

(0029563)
Andreas Mohr (reporter)
2012-05-24 15:11

I'm not quite sure about the state of the discussion or which solutions would prove helpful, but given a version detection problem of the toolchain commands (insufficiently verbose version information) perhaps an (albeit awfully dirty) way to differentiate toolchains would be to do a
file(READ ... LIMIT ... OFFSET ...)
(and do some string matching)
on the actual toolchain binary itself (or an important helper library dependency) to figure out whether we're dealing with the GNU or MSVC compat variant.

(0029564)
Brad King (manager)
2012-05-24 15:25

Re 0013035:0029563: Detecting the variant is not a problem. It's configuring CMake's generation process to produce the corresponding command lines appropriately that will take some work.

The pure MinGW case is solved by adding Platform/Windows-Clang-(C|CXX).cmake modules to CMake that forward to the GNU versions.

(0033973)
Brad King (manager)
2013-10-04 13:56

Okay, I've installed both Clang for MinGW and Clang CL (see issue 0014458) and got things working. First I had to introduce the notion of one compiler simulating another, used to detect the difference between the GNU-like and MS-like Clang:

CMakeDetermineCompilerId: Add notion of "simulated" id/version
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51ab85c3 [^]

Then I added the platform files to use this information to load either GNU or MSVC flags:

Clang: Support Windows variants for GNU and MSVC
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d8356d4 [^]

(0033975)
Brad King (manager)
2013-10-04 13:58

Please try out CMake from Git commit 3d8356d4.

(0034075)
Brad King (manager)
2013-10-08 11:21

The changes mentioned in 0013035:0033973 are now in master, having been tested successfully as reported in issue 0014458.

(0035276)
Robert Maynard (manager)
2014-03-05 09:58

Closing resolved issues that have not been updated in more than 4 months

Notes
(0028890) Brad King (manager) 2012-03-12 09:10	The Modules/Platform/Windows-GNU-(C\|CXX\|Fortran).cmake files contain the Windows-specific (MinGW) rules for the GNU compiler. Similar files will need to be written for Clang, called Modules/Platform/Windows-Clang-(C\|CXX).cmake.

(0028910) rubenvb (reporter) 2012-03-13 16:12	OK, adding Windows-Clang-[C\|CXX].cmake files that are pure copies does the trick for MinGW related Clang. Before I submit a patch, I'd like for the MSVC-built Clang to work as well. Is there any pre-existing example I can check out to read "clang --version" output and parse it to differentiate? Thanks!

(0028911) Brad King (manager) 2012-03-13 16:22	If we were to support only the MinGW version, then since Clang strives to be command-line compatible with GCC rather than copies perhaps just include the GNU ones: # Platform/Windows-Clang-C.cmake include(Platform/Windows-GNU-C) This is already done for "Compiler/Clang-(C\|CXX).cmake". The situation is more complicated if we want to support MSVC-style Clang too. Does the MSVC-built Clang try to be command-line compatible with MSVC? Does MinGW-style Clang define __GNUC__? Does MSVC-style Clang define _MSC_VER? If the answer to the above three questions is "yes" then we probably need to distinguish the two compilers with separate compiler ids. Instead of just "Clang" we may need to use "ClangMS" and "ClangGNU" or something like that. Alternatively we would need to introduce the notion of a secondary id. This problem already partially exists for the Intel compiler except that it is always GNU-style on Linux and MSVC-style on Windows so we can distinguish them by separating Platform/Windows-Intel-* and Platform/Linux-Intel-*.

(0029558) Brad King (manager) 2012-05-24 13:11	Related mailing list discussion: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42389 [^] http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42398 [^]

(0029560) rubenvb (reporter) 2012-05-24 14:16	The proposal in the mailing list discussion would work, except for the fact that Clang does not have a cl-compatible driver right now. They still plan to have one someday, but don't expect that to happen anytime soon. The only thing differentiating the two Clang versions is the "binutils" part, which should be eg. link.exe for the MSVC one and ar.exe for the MinGW one. I noticed the CMake variables are wildly different in the two cases. So there needs to be some way to pull in the GNU compiler options along with the MSVC tool options. I don't know if this kind of splitting is already present. Also: perhaps an "if" on CMAKE_GENERATOR being "MinGW Makefiles" or "MSYS Makefiles" vs everything else (ie MSVC) is better than the platform id, maybe not. I don't know.

(0029561) Brad King (manager) 2012-05-24 14:25	Re 0013035:0029560: The platform id is computed from the toolchain in use so we know what the compiler targets. I think it is the right thing to use. I hadn't thought of it when I wrote 0013035:0028911. Do the platform files proposed in that thread: $ cat Platform/Windows-Clang-C.cmake if("${CMAKE_C_PLATFORM_ID}" MATCHES "MinGW") include(Platform/Windows-GNU-C) else() include(Platform/Windows-cl) endif() $ cat Platform/Windows-Clang-CXX.cmake if("${CMAKE_CXX_PLATFORM_ID}" MATCHES "MinGW") include(Platform/Windows-GNU-CXX) else() include(Platform/Windows-cl) endif() work for you?

(0029562) rubenvb (reporter) 2012-05-24 14:28	For MinGW: yes, perfectly. For MSVC: no: it tries to locate GNU binutils which aren't what MSVC-built Clang uses. It relies on MSVS link.exe and friends.

(0029563) Andreas Mohr (reporter) 2012-05-24 15:11	I'm not quite sure about the state of the discussion or which solutions would prove helpful, but given a version detection problem of the toolchain commands (insufficiently verbose version information) perhaps an (albeit awfully dirty) way to differentiate toolchains would be to do a file(READ ... LIMIT ... OFFSET ...) (and do some string matching) on the actual toolchain binary itself (or an important helper library dependency) to figure out whether we're dealing with the GNU or MSVC compat variant.

(0029564) Brad King (manager) 2012-05-24 15:25	Re 0013035:0029563: Detecting the variant is not a problem. It's configuring CMake's generation process to produce the corresponding command lines appropriately that will take some work. The pure MinGW case is solved by adding Platform/Windows-Clang-(C\|CXX).cmake modules to CMake that forward to the GNU versions.

(0033973) Brad King (manager) 2013-10-04 13:56	Okay, I've installed both Clang for MinGW and Clang CL (see issue 0014458) and got things working. First I had to introduce the notion of one compiler simulating another, used to detect the difference between the GNU-like and MS-like Clang: CMakeDetermineCompilerId: Add notion of "simulated" id/version http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51ab85c3 [^] Then I added the platform files to use this information to load either GNU or MSVC flags: Clang: Support Windows variants for GNU and MSVC http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d8356d4 [^]

(0033975) Brad King (manager) 2013-10-04 13:58	Please try out CMake from Git commit 3d8356d4.

(0034075) Brad King (manager) 2013-10-08 11:21	The changes mentioned in 0013035:0033973 are now in master, having been tested successfully as reported in issue 0014458.

(0035276) Robert Maynard (manager) 2014-03-05 09:58	Closing resolved issues that have not been updated in more than 4 months

Issue History
Date Modified	Username	Field	Change
2012-03-10 07:57	rubenvb	New Issue
2012-03-12 09:10	Brad King	Note Added: 0028890
2012-03-12 09:10	Brad King	Status	new => backlog
2012-03-13 11:13	Brad King	Severity	major => feature
2012-03-13 11:13	Brad King	Summary	Setting CMAKE_CXX_COMPILER=clang++ on Windows links to .lib files even though clang is built with/for MinGW(-w64) => Support for MinGW Clang on Windows
2012-03-13 16:12	rubenvb	Note Added: 0028910
2012-03-13 16:22	Brad King	Note Added: 0028911
2012-05-24 13:11	Brad King	Note Added: 0029558
2012-05-24 14:16	rubenvb	Note Added: 0029560
2012-05-24 14:25	Brad King	Note Added: 0029561
2012-05-24 14:28	rubenvb	Note Added: 0029562
2012-05-24 15:11	Andreas Mohr	Note Added: 0029563
2012-05-24 15:25	Brad King	Note Added: 0029564
2013-10-04 09:21	Brad King	Relationship added	related to 0014458
2013-10-04 13:56	Brad King	Assigned To	=> Brad King
2013-10-04 13:56	Brad King	Status	backlog => assigned
2013-10-04 13:56	Brad King	Target Version	=> CMake 3.0
2013-10-04 13:56	Brad King	Note Added: 0033973
2013-10-04 13:58	Brad King	Note Added: 0033975
2013-10-08 11:21	Brad King	Note Added: 0034075
2013-10-08 11:21	Brad King	Status	assigned => resolved
2013-10-08 11:21	Brad King	Resolution	open => fixed
2013-10-08 11:21	Brad King	Fixed in Version	=> CMake 3.0
2014-03-05 09:58	Robert Maynard	Note Added: 0035276
2014-03-05 09:58	Robert Maynard	Status	resolved => closed