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

[csiga.biga at aol.com]

 I was just about to write a mail with similar content than this one, so allow me to add my 5 cents.
Fear of reyling on defaults in case Microsoft decides to change them?
1) Defaults don't change often. BTW, don't we rely on defaults for GCC and Clang anyway?2) Defaults change to benefit users. If the default changes from /W3 to /W4 per say, it would be because windows.h headers and the STL would be cleaned up for the warnings in /W4 and MS felt that it would be better if users relied on all the warning they packed there. (Currently it is not the case)
As for having to call string() on CMAKE_CXX_FLAGS to up my warning level for a single compiler... these sort of idiosincrecies are the ones that drive people away from CMake to Meson and other, more modern build systems. Not being able to clean up decades worth of sediments in script style will result in CMake's demise.

if (MSVC)  string(REGEX REPLACE "/W[0-9]""" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})endif (MSVC) add_executable(${PROJECT_NAME}main.cpp) target_compile_options(${PROJECT_NAME}PRIVATE$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall-Wextra -pedantic>                                          $<$<CXX_COMPILER_ID:MSVC>:/W4>) 
Instead of
 add_executable(${PROJECT_NAME}main.cpp) target_compile_options(${PROJECT_NAME}PRIVATE$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall-Wextra -pedantic>                                          $<$<CXX_COMPILER_ID:MSVC>:/W4>)
Or even
add_executable(${PROJECT_NAME}main.cpp)
set_target_properties(${PROJECT_NAME}PROPERTIES WARNING_LEVEL HIGH)
is nonsense. There should be direct support for a few pre-defined, commonly accepted warning levels. If not this, having to explain to C++ freshmen why we're running regexes over lists default args to clean them up BEFORE even stating our bussiness...


Please, remove this default because it hurts CMake as a whole.
Cheers,Máté

-----Original Message-----
From: Mateusz Loskot <mateusz at loskot.net>
To: marc.chevrier <marc.chevrier at gmail.com>
Cc: cmake-developers <cmake-developers at cmake.org>; cmake <cmake at cmake.org>
Sent: Sun, Dec 9, 2018 2:55 pm
Subject: Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER <marc.chevrier at gmail.com> wrote:
>
> I think the discussion is shifting from the initial problem which was unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' ».

I disagree with your opinion.
Fixing just the warning would be a symptomatic treatment.

> 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.

Although I think it is a long shot at something that is (highly)
unlikely to change, YAGNI consideration,
I understand CMake developers may be reluctant to change the long-time defaults.

> The real question is how to manage cleanly target specific flags overriding global or directory defaults?

>From end-user point of view (I have not checekd CMake implementation),
I'd either do not explicitly set -W defaults or strip any -W option
prior re-setting
with (possibly) new value passed to target_compile_options.

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-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190221/fb2ef42b/attachment-0001.html>