[PATCH] [CMake] Don't pass in MSVC warning flags as definitions

Greg Bedwell greg_bedwell at sn.scee.net
Thu Mar 12 09:15:27 PDT 2015


Thanks for the review!  I committed at r231924 but got a new failure on the sanitizer-windows bot so reverted at r231925 to give me time to investigate.

The errors introduced were in the form:
clang.exe: error: unknown argument: '-wd4146'

I can see now that in compiler-rt, CMAKE_C_FLAGS gets passed into clang.exe command lines even when guarded by (MSVC).

My first thought was to make use of HandleLLVMOptions.cmake's add_flag_if_supported macro to ensure that the flag is actually supported by the compiler.  I had to modify it slightly to make it work for MSVC as it implicitly expects the compiler to support the -Werror flag, but sadly no luck.  It performs the test against cl.exe but still then still adds it to the clang.exe command line later on.

It seems like a potential solution may be to add a filter to CompilerRTCompile's clang_compile macro to remove MSVC specific flags like this at the same time that it replaces '/' with '-'.  I'll proceed to try that solution in the meantime, but any other suggestions are more than welcome.

To re-summarize the problem I'm trying to solve:

- currently MSVC warning flags are added as definitions rather than as flags
- I want to make a change to use the Microsoft resource compiler to embed Windows version metadata in our exe and dll files.
- With CMake's Visual Studio generators definitions are automatically filtered to remove anything invalid when using the resource compiler
- With CMake's Ninja generator and MSVC all definitions are passed through to the resource compiler unfiltered
- The warning flags are not valid for the resource compiler causing it to fail with an unknown flag error.
- This patch adds the warning flags as flags rather than as definitions which fixes the above problem, but introduces a new problem in compiler-rt as these flags are then passed into both cl.exe and clang.exe, for the latter of which the flags are invalid, causing an error.

Thanks,

-Greg


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8188

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list