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

[Craig Scott]

>From what I understand from a very limited quick search just now, it seems
that /W3 is the default warning level for Visual Studio (according to
the Microsoft
docs
),
but CMake explicitly adds it

as a default compiler flag in CMAKE__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. 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. I've CC'ed
the developer's list and suggest that follow-up discussion should occur
there.


On Sun, Dec 9, 2018 at 8:07 AM Mateusz Loskot  wrote:

> Hi,
>
> I define a target for a library, and set warning level for MSVC compiler:
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> Although this works well, the compiler throws this warning:
>
> cl : Command line warning D9025: overriding '/W3' with '/W4'
>
> I want to get rid of this warning, so I fix it this way
>
> if(MSVC)
>   string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>   string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif()
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> This works like charm, but leaves me with sour feeling that
> something is not right here.The REGEX REPLACE clean-up
> has become such a habit, it's almost canonical thing I do in
> all my CMake-based projects.
>
> Shouldn't CMake drop the default when target_compile_options is called?
> Is this behaviour by design, for MSVC?
> Could anyone help me to understand if this is actually a bug
> or am I misunderstanding anything?
>
> 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
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide

-- 

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

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Craig Scott]

On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki  wrote:

> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
> >
> > However from my point of view and my cross-compiling experience when you
> cross-compile you have:
> >
> > 1) the host compiler which is used to compile "host tools"
> > 2) the target compiler (may be several of them) to "cross-compile"
> >
> > My assumption are:
> >  a) when you cross-compile your build is a "whole" and you shouldn't
> have to setup some superbuild
> >structure for building host tools ht_exe and another for target1 tool
> t1t_exe and another one for target2 tool t2t_exe.
> >
> >  b) what you want is to build:
> >  ht_exe for the host
> >  possibly use ht_exe during the build to generate some [source] file
> >  t1t_exe for the [cross]target1
> >  t2t_exe for the [cross]target2
> >
> >  c)  you seldomly compile the same source for the host AND the target,
> but it may happen.
>
> In case, you are doing unit tests, it’s normal to have the same code
> running in a test on the host platform and in the final binary on the
> target.
>
> I think, having more than 1 target platform becomes more and more normal
> as it becomes more usual to have multiple microcontrollers in a project.
>
> Previously, I have encoded this in the build type. So instead of just
> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
> much, that I have to run CMake 3 times to get all the binaries for a
> release build. The problem that I have, are dependencies between this
> builds. If I write a tool that (for example) generates source files for one
> of the target platforms, the build for the host platform must run before
> the build for that target platform. And when I make changes to that tool, I
> want the build to regenerate the generated source files.
>
> Keeping track of this dependencies to solve this kind of ordering issues
> and to allow minimum rebuilds, is the main purpose of any build system. To
> solve this with CMake, I think we need a way to define the dependencies
> between build types (in the example above, from the generator from the host
> build to the generated source file in one of the target builds) and CMake
> needs to know the build directory for all build types (not only the
> current).
>

Perhaps a superbuild would be the cleanest approach here? The host tools
would be one subproject and the cross-compile builds would depend on the
host tools' build. You could then choose to build everything via the top
level superbuild or just work on one of the subprojects if that's all you
needed once the initial tools build had been done. You could even set up as
many different sub-projects for the different architectures as needed.
Packaging would require a little more work, but it shouldn't be
prohibitively so.

Another alternative is the approach described in this stackoverflow article

which performs the host tools build off to the side in a secondary build
during configure. This works well when the host tools don't change much (we
use it extensively at work with very large, complex hierarchical projects).
It wouldn't help though if you need to build more than one cross-compiled
architecture.



> > The wish-season is coming up, so that's sort of what I would like to
> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>
> How about ``add_dependencies()`` allowing me to define dependencies
> between different build types? :-)
>

A superbuild would already give you the equivalent capability.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide

-- 

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

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

[Mateusz Loskot]

On Sun, 9 Dec 2018 at 12:14, Craig Scott  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__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-developers

Re: [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 , a écrit :
> On Sun, 9 Dec 2018 at 12:14, Craig Scott  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__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
-- 

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

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

[Mateusz Loskot]

On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER  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

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

[Ray Donnelly]

Cmake is already full of do much hardcoded logic / flags and does new
releases so frequently (maybe there's some correlation between these two)
that adding this would hardly impact upon its quality or maintainability.

So to that end, hardcoding the default per msvc version so that it's not
added unnecessarily, triggering this warning would seem appropriate to me.
Either that or disabling this warning with more hard coded flags would also
be appropriate.

The current status in not ideal.

On Sun, Dec 9, 2018, 7:55 AM Mateusz Loskot  On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER 
> 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
>
-- 

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