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

[Brad King via cmake-developers]

On 12/9/18 8:09 AM, Marc CHEVRIER wrote:
> The real question is how to manage cleanly target specific flags
> overriding global or directory defaults?

All the optimization and warning flags currently handled by
`CMAKE__FLAGS[_]` need to have abstractions
introduced (e.g. target properties or something) and the
defaults re-thought.  Transition can be handled via a policy.

-Brad
-- 

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 Mon, Dec 10, 2018 at 7:57 PM Eric Noulard  wrote:

>
> Le dim. 9 déc. 2018 à 12:24, Craig Scott  a
> écrit :
>
>> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
>> wrote:
>>
>>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>>> >
>>> > 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.
>>>
>>
> Yes that's why I thought it was worth going further than host + target,
> but host + tgt1 + tg2 + 
>
>
>>
>>> 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.
>>
>
> I guess the tough part is to find a [light] way to specify dependencies
> between host target build and the various target builds.
>
>
>> 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.
>>
>
> Not as easy as it seems right?
> I bet you know it well as you listed the dependencies shortcoming of
> adding dependencies for External_ProjectAdd in your book (§27.1.4).
>

For a strict superbuild arrangement, handling straight dependencies to get
build order correct is not too bad. This is what I was thinking of with my
earlier comment that super builds essentially give you the equivalent
capability as just using add_dependencies(). You can also usually define
CMAKE_PREFIX_PATH to pass sub-project install locations between the
sub-projects and they each find what they need from the others without much
further help. The top level superbuild is then really just specifying which
sub-projects depend on which other ones. That does require a little bit of
boilerplate, agreed, but not crazy amounts.

Where it starts getting out of hand is when you want to have a main build
that directly wants/needs to refer to targets from sub-projects brought in
by ExternalProject. Then 

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

[Eric Noulard]

Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > 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.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


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

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


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

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
Eric
-- 

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

[Eric Noulard]

Le mer. 28 nov. 2018 à 21:03, Rolf Eike Beer  a écrit :

> Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard:
>
> > I think that most of the time specifying the toolchain on the command
> line
> > drives you to some superbuild structure.
>
> Which is not bad by itself, but I would like to see that CMake can provide
> things that avoid people reinventing the boilerplate code, and probably
> getting them wrong at least 80% of the time. Like they would do with
> dependencies and other things if they would write their Makefiles by hand
> instead of using CMake, just one level higher.
>

I do totally agree with this.
Superbuild is nice but you have to write a lot of boilerplate CMake code
*each time* you want to do it.
May be a good path would be to have a "builtin" support for superbuild in
CMake which
would make its usage lighter than the usual ExternalProject_Add.

When ones do cross compile for the host + one or several target a lighter
"add_superbuild"
API could be design. I'll try to think about it more thoroughly and do some
proposal.
Ideally we shouldn't need to provide many parameters beside the toolchain
and a way
to specify "the host build".


>
> > > 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 ;)
> >
> > I wish an integrated multi-target cross building support in CMake with
> > little or no flow-control scripting command in the CMakeLists.txt.
>
> That would mean introducing HOST and TARGET flags to every find_* call,
> I'm
> not sure if that is cleaner than explicit if()'s. But I'm not
> fundamentally
> opposed to it, I'm just not sure it's worth the effort.
>

Sure, I agree too.
May not be worth, let's dig the "light superbuild" approach a little
further first.

-- 
Eric
-- 

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