Le dim. 9 déc. 2018 à 12:24, Craig Scott <craig.sc...@crascit.com> a écrit :
> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki <tors...@robitzki.de> > wrote: > >> > Am 27.11.2018 um 19:55 schrieb Eric Noulard <eric.noul...@gmail.com>: >> > >> > 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 > <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run> > 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