<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 10, 2018 at 7:57 PM Eric Noulard <<a href="mailto:eric.noulard@gmail.com">eric.noulard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Le dim. 9 déc. 2018 à 12:24, Craig Scott <<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>> a écrit :</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki <<a href="mailto:Torsten@robitzki.de" target="_blank">Torsten@robitzki.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> Am 27.11.2018 um 19:55 schrieb Eric Noulard <<a href="mailto:eric.noulard@gmail.com" target="_blank">eric.noulard@gmail.com</a>>:<br>
> <br>
> My assumption are:<br>
> a) when you cross-compile your build is a "whole" and you shouldn't have to setup some superbuild<br>
> structure for building host tools ht_exe and another for target1 tool t1t_exe and another one for target2 tool t2t_exe.<br>
> <br>
> b) what you want is to build:<br>
> ht_exe for the host<br>
> possibly use ht_exe during the build to generate some [source] file<br>
> t1t_exe for the [cross]target1<br>
> t2t_exe for the [cross]target2<br>
> <br>
> c) you seldomly compile the same source for the host AND the target, but it may happen.<br>
<br>
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.<br>
<br>
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.<br></blockquote></div></div></blockquote><div><br></div><div>Yes that's why I thought it was worth going further than host + target, but host + tgt1 + tg2 + ....</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
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).<br></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>I guess the tough part is to find a [light] way to specify dependencies between host target build and the various target builds.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Another alternative is the approach described in <a href="https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run" target="_blank">this stackoverflow article</a> 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> The wish-season is coming up, so that's sort of what I would like to<br>
> have. Now it's your turn. No bikeshedding please, only deliveries ;)<br>
<br>
How about ``add_dependencies()`` allowing me to define dependencies between different build types? :-)<br></blockquote><div><br></div><div>A superbuild would already give you the equivalent capability.</div></div></div></blockquote><div><br></div><div>Not as easy as it seems right? </div><div>I bet you know it well as you listed the dependencies shortcoming of adding dependencies for External_ProjectAdd in your book (§27.1.4).</div></div></div></blockquote></div><div><br></div><div>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.</div><div><br></div><div>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 you have to go working out where everything is without much help from CMake and that can be a soul-destroying exercise for complex multi-platform projects. Packaging suffers from this if done from the top superbuild project, but the difficulty can sometimes be reduced by doing the packaging itself as another subproject and importing what it needs from the others (you can then use the various imported targets, etc. to locate things), but it's still not particularly clean.</div><div><br></div><div>But yes, I'm agreeing with you, it isn't all that simple once you start considering the full software delivery process (i.e. going beyond more than just getting things to build).</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>New book released: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div>