Fix GNU-style flag passing to MSVC frontend#2391
Fix GNU-style flag passing to MSVC frontend#2391stephenberry merged 2 commits intostephenberry:mainfrom
Conversation
|
I also wanted to ask if there's a reason why |
|
hmm, I guess we can also simplify these checks, so instead of if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" OR CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "MSVC")
# Something for compiler with MSVC command line style
endif()we can use if(MSVC)
# Something for compiler with MSVC command line style
endif()since, as stated in CMake MSVC variable documentation, it is should we change our current approach ( |
|
seems like Line 22 in 6a7d699 so I replaced the long if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" OR CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "MSVC") with if(MSVC)
|
|
Thanks for this contribution for clang-cl. I'll look it over in a bit more detail ASAP. But, I'm also open for a PR that tests clang-cl if you'd like to add it. |
|
Looks good! |
Issue
When building
glazewithclang-cl, the build fails because some branches intests/CMakeLists.txtandfuzzing/CMakeLists.txtselect GNU-style flags based only onCMAKE_<LANG>_COMPILER_ID=ClangThis is incorrect for
clang-cl: although the compiler ID isClang, its frontend is MSVC-compatible and therefore expects MSVC-style command-line options. To solve this issue, CMake introduced CMAKE_LANG_COMPILER_FRONTEND_VARIANT flag in v3.14Fix
This PR updates the compiler checks in
tests/CMakeLists.txtandfuzzing/CMakeLists.txtto account for the frontend variant, soclang-clno longer enters the GNU-style flag branch. As a result, the affected targets configure and build correctly withclang-clgotta see what CI will say, and if there are any issues (which shouldn't be the case, but who knows 😁), I'll take care of them
P.S. I also removed
target_link_options(glz_test_common INTERFACE -ftime-trace)sincetarget_link_options()applies to the linker, while afaik the flag is intended for compile-time tracing