[cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

[Marc CHEVRIER]

I think the discussion is shifting from the initial problem which was unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' ».

Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour.

Moreover, removing ‘/W3’ from defaults will remove the warning for this flag but the problem remains for all other flags possibly overloaded.

The real question is how to manage cleanly target specific flags overriding global or directory defaults? And the frustrating thing is that cl.exe do not allow to disable D9025 warning! :(

Le 9 déc. 2018 à 13:32 +0100, Mateusz Loskot <mateusz at loskot.net>, a écrit :
> On Sun, 9 Dec 2018 at 12:14, Craig Scott <craig.scott at crascit.com> wrote:
> >
> > From what I understand from a very limited quick search just now,
> > it seems that /W3 is the default warning level for Visual Studio
>
> Yes, it is the default level indeed.
>
> > but CMake explicitly adds it as a default compiler flag in CMAKE_<LANG>_FLAGS_INIT.
> > This makes me wonder if it has always been the default, otherwise it isn't clear why it was deemed necessary to add it.
>
> Yes, I'd suspect it was added as 'just in case' too eagerly.
>
> > More to the point, unless there's a reason not to, perhaps we could consider removing it from the default flags CMake sets.
> > I think this would largely address the situation you're describing and shouldn't actually change the behavior of existing projects.
>
> Yes, it should be removed.
> Unless I'm missing an important reason behind the explicit -W3.
>
> No, "This has been the default since CMake began" [1], is not enough
> rationale to keep it.
>
> In the old times of manual editing of CMAKE_CXX_FLAGS, it was not a huge deal
> - in fact, fiddling with CMAKE_CXX_FLAGS was quite canonical way of
> doing things..
> But with the advent of target_compile_options, the string call
> requirement is just unacceptable.
>
> [1] https://gitlab.kitware.com/cmake/cmake/issues/18317
>
> > I've CC'ed the developer's list and suggest that follow-up discussion should occur there.
>
> FYI, I've just subscribed to the developer's list.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181209/b9ff97df/attachment-0001.html>