SergiusTheBest / FindWDK

CMake module for building drivers with Windows Development Kit (WDK)
BSD 3-Clause "New" or "Revised" License
251 stars 53 forks source link

cl : Command line warning D9025 : overriding '/GR' with '/GR-' #17

Open TheJCAB opened 4 years ago

TheJCAB commented 4 years ago

wdk_add_driver and wdk_add_driver add the compilation switch /GR-, which conflicts with /GR normally added by CMake (found with CMake 3.18 with Ninja and MSVC 16.8 preview, x64).

Q: Would there be a way to remove existing compilation flags for WDK targets? I noticed all the user-mode stuff is there when building a kernel driver, including inappropriate stuff: UCRT include directories, references to kernel32.lib and friends... even exception modes (/EHsc).

TheJCAB commented 4 years ago

I didn't find an issue for this, but after sending a PR, I noticed by chance that there's a closed (not used) PR that attempted to solve this.

1

I experience this issue by building with Ninja (instead of MSBuild). I hadn't noticed the warning level mismatch until I tried to build the samples directory in this repo (prior to sending my PR), but it did happen then.

It would be great to try and fix this. In that old PR the solution was a REGEX REPLACE of CMAKE_CXX_FLAGS. But CMAKE_CXX_FLAGS is not project specific. But something like it should hopefully work on the COMPILE_OPTIONS target property (get_target_property + modify + set_target_properties). And maybe a regex is not needed. COMPILE_OPTIONS is a list of options, so maybe "list(REMOVE_ITEM" would suffice for simple things like /GR (the /W3 vs /W4 mismatch seems to come from the root CMakeLists.txt just appending /W4 - so the /W3 must come from the generator).

Of course, YMMV with respect to the version of CMake you may be using...

I might try to dabble in this.

SergiusTheBest commented 4 years ago

I might try to dabble in this.

Yes, please. Also we can rise CMake version if it helps.

TheJCAB commented 4 years ago

Progress report: no dice. What I said doesn't work at all, because the compiler flags (CMAKE_CXX_FLAGS) are not copied to any target properties. They are pre-pended in the generator when generating the target build rules. So the only way to avoid them is to make sure CMAKE_CXX_FLAGS is empty when the rule generation happens.

For the Ninja generator (which I'm using), it would be sufficient to add this line to the two target functions in this module:

set(CMAKE_CXX_FLAGS "" PARENT_SCOPE)

PARENT_SCOPE is unfortunately necessary. Target generation seems to happen after processing the corresponding CMakeLists.txt, so that the variable needs to remain empty after/outside of the calls to the wdk_add_driver and wdk_add_Library functions.

This means that the flags will be empty for all targets defined in the same CMakeLists.txt file which is... unsavory, but it can be documented as a requirement and easily understood: "all executable and library targets in the file must be WDK targets".

You would think that they could have had add_executable() just grab all the variables it needs and copy them into target properties. But alas... no.

I only looked at the compilation flags, not the definitions or include directories. But I expect those to work similarly.

I also only tried Ninja. I hope other generators work the same. But I can't guarantee it.

Thoughts?

TheJCAB commented 4 years ago

Ooohhh... I spotted an issue in CMake's own DB: https://gitlab.kitware.com/cmake/cmake/-/issues/19084

It describes almost exactly what I'm seeing. I'll put my thoughts there, see what happens.