From Torsten at Robitzki.de Tue Dec 4 02:56:07 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Tue, 4 Dec 2018 08:56:07 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> > 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). > 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? :-) best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Alan.W.Irwin1234 at gmail.com Tue Dec 4 16:08:27 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 4 Dec 2018 13:08:27 -0800 (PST) Subject: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests Message-ID: Three dashboards for PLplot submitted today at had a build warning concerning ctest. For example, contained Build Warnings (1) *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe which I have never seen before, and the test summary section contained (just) the following message 0 passed, 0 failed, 0 failed for timing, 0 not run. (which I have also never seen before). A PLplot peculiarity is that all tests depend on bash scripts so if bash.exe is not available (as in this user's case) then there will be no ctest tests configured. In an attempt to replicate this issue, I forced bash not to be found on my own Linux box which guaranteed no add_test logic was executed. However, instead of the above results here was the reasonable PLplot "no-test" result from ctest (version 3.13.1): software at merlin> ctest Test project /home/software/plplot/HEAD/build_dir No tests were found!!! software at merlin> echo $? 0 So I would have expected the same reasonable "no-test" result on this user's Windows machine (where he was also using ctest-3.13.1), but instead he is generating the above peculiar results. Can someone here shed some light on this issue? For example, could this be a ctest bug for the "no-test" case that this user's platform exposes? Or could this be a cdash issue when a dashboard is submitted with the above reasonable "no-test" results I got on Linux? Note, there cannot be much wrong with the normal PLplot configuration of ctest when most of our ~30 tests are configured since I have recently submitted (see, e.g., ) successful dashboards for a fully loaded Linux systems, and Arjen Markus has done the same thing previously for his fully loaded Cygwin and MinGW-w64/MSYS2 platforms. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Wed Dec 5 09:22:04 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 5 Dec 2018 09:22:04 -0500 Subject: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests In-Reply-To: References: Message-ID: On 12/4/18 4:08 PM, Alan W. Irwin wrote: > Build Warnings (1) > > *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe That's in the "Build" section and indicates that the build command exited with non-zero status. If you want to try to reproduce that by hand, run the `cmake --build . --config Debug` command rather than `ctest`. `cmake --build`'s exit code just forwards from the native build tool. It may be that MSBuild has chosen to exist with non-zero for some reason. -Brad From Alan.W.Irwin1234 at gmail.com Wed Dec 5 15:37:12 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Wed, 5 Dec 2018 12:37:12 -0800 (PST) Subject: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests In-Reply-To: References: Message-ID: On 2018-12-05 09:22-0500 Brad King via cmake-developers wrote: > On 12/4/18 4:08 PM, Alan W. Irwin wrote: >> Build Warnings (1) >> >> *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe > > That's in the "Build" section and indicates that the build command > exited with non-zero status. If you want to try to reproduce that > by hand, run the `cmake --build . --config Debug` command rather > than `ctest`. > > `cmake --build`'s exit code just forwards from the native build tool. > It may be that MSBuild has chosen to exist with non-zero for some reason. Hi Brad: Did you mean "ctest --build-and-test ..." rather than "cmake --build ..."? I assume if the build part of "ctest --build-and-test ..." returned with some non-zero return code, then you would get a message like the above that mentions ctest in a way that implies it is running the show. But I cannot see any way you could get such a WARNING message from "cmake --build ...". I hasten to add that I have been completely content over the years to use cmake, make, and ctest separately, and I have no experience using them in an integrated way (e.g., "cmake --build ..." or "ctest --build-and-test ..."). So my comment is based on my quick reading the appropriate sections of the man pages for cmake and ctest this morning, and I may have missed some way that a cmake command could generate what appears to be a message from ctest. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From Alan.W.Irwin1234 at gmail.com Wed Dec 5 17:01:46 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Wed, 5 Dec 2018 14:01:46 -0800 (PST) Subject: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests In-Reply-To: References: Message-ID: On 2018-12-05 12:37-0800 Alan W. Irwin wrote: > On 2018-12-05 09:22-0500 Brad King via cmake-developers wrote: > >> On 12/4/18 4:08 PM, Alan W. Irwin wrote: >>> Build Warnings (1) >>> >>> *** WARNING non-zero return value in ctest from: >>> C:\cmake-3.13.1-win64-x64\bin\cmake.exe >> >> That's in the "Build" section and indicates that the build command >> exited with non-zero status. If you want to try to reproduce that >> by hand, run the `cmake --build . --config Debug` command rather >> than `ctest`. >> >> `cmake --build`'s exit code just forwards from the native build tool. >> It may be that MSBuild has chosen to exist with non-zero for some reason. > > Hi Brad: > > Did you mean "ctest --build-and-test ..." rather than "cmake --build > ..."? I assume if the build part of "ctest --build-and-test ..." > returned with some non-zero return code, then you would get a message > like the above that mentions ctest in a way that implies it is running > the show. But I cannot see any way you could get such a WARNING > message from "cmake --build ...". I hasten to add that I have been > completely content over the years to use cmake, make, and ctest > separately, and I have no experience using them in an > integrated way (e.g., "cmake --build ..." or "ctest --build-and-test > ..."). So my comment is based on my quick reading the appropriate > sections of the man pages for cmake and ctest this morning, and I may > have missed some way that a cmake command could generate what appears > to be a message from ctest. Never mind, I got it wrong. I was too focussed on the "ctest" in the above message, and it pretty clearly was issued "from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe" But I still don't understand exactly how ctest is run from cmake. Assuming the "test" target (which I have never tried) runs the "all" target and then ctest, I guess cmake --build . --config Debug --target test would run ctest indirectly after the "all" target was built, although I haven't yet figured out how in this case that user specified the -D option to submit a dashboard for that indirect ctest command. But even if that puzzle can be solved, the above message does mention ctest so I am pretty sure the above message is not coming from that "all" target. Which means ctest itself is sending a non-zero return code. And for the "--target test" case I don't see how that indirect ctest command could actually build anything. Anyhow, if you still feel the above rather opaque message was really from a PLplot build error on this guy's platform, then it appears to me (since both cmake and ctest are mentioned in the message) that it must be from cmake calling ctest which calls the build tool, but I don't see how that is possible. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Thu Dec 6 06:53:53 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Dec 2018 06:53:53 -0500 Subject: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests In-Reply-To: References: Message-ID: <7e28dba9-4f7e-3387-d173-17f81097bc2d@kitware.com> On 12/5/18 5:01 PM, Alan W. Irwin wrote: > But I still don't understand exactly how ctest is run from cmake. Assuming the > "test" target (which I have never tried) runs the "all" target and then ctest, > I guess > > cmake --build . --config Debug --target test > > would run ctest indirectly after the "all" target was built cmake does not run ctest. ctest is driving the dashboard client build. First it configures the project. Then it builds the project. Then it runs the tests. The "build the project" step means it needs to run the native build tool. ctest uses "cmake --build . --config Debug" to do that. The native build tool somehow exits non-zero, and "cmake --build" returns that error code. As far as "ctest" knows, "cmake --build ..." is the build tool, and it exited with non-zero. That is why the message appears. -Brad From craig.scott at crascit.com Sun Dec 9 06:14:22 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 9 Dec 2018 22:14:22 +1100 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Dec 9 06:23:59 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 9 Dec 2018 22:23:59 +1100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Sun Dec 9 07:31:39 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun, 9 Dec 2018 13:31:39 +0100 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: 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 From marc.chevrier at gmail.com Sun Dec 9 08:09:28 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Sun, 9 Dec 2018 14:09:28 +0100 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Sun Dec 9 08:55:21 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Sun, 9 Dec 2018 14:55:21 +0100 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: 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 From mingw.android at gmail.com Sun Dec 9 10:02:38 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Sun, 9 Dec 2018 09:02:38 -0600 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 10 03:45:15 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 10 Dec 2018 09:45:15 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: <4054095.oukdIuTTYd@daneel.sf-tec.de> References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <4054095.oukdIuTTYd@daneel.sf-tec.de> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 10 03:57:24 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 10 Dec 2018 09:57:24 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Dec 10 05:22:31 2018 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 10 Dec 2018 21:22:31 +1100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <8F791FB5-4DA3-4353-A04E-3D809ED9976C@Robitzki.de> Message-ID: 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 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. 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). -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Dec 10 07:16:38 2018 From: brad.king at kitware.com (Brad King) Date: Mon, 10 Dec 2018 07:16:38 -0500 Subject: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug In-Reply-To: References: Message-ID: <4c137c69-702d-5fe6-d01d-f1bb7ad51786@kitware.com> 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 From eike at sf-mail.de Tue Dec 11 08:17:58 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 11 Dec 2018 14:17:58 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <4054095.oukdIuTTYd@daneel.sf-tec.de> Message-ID: Eric Noulard wrote: > 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". I guess putting the host-build location in the toolchain file could be one way to just get it done. In case one has multiple builds that should share one host build then just set an absolute location, and if you don't it will be below your normal build directory. There are just 2 things that scare me a bit off: we surely want a way to break that into smaller pieces so we can introduce it over multiple releases, maybe even as a tech-preview so we can break things if we see that we have not taken a bigger usecase in account, and I currently don't see the points to slice that up. And we really, really want a .cmake_no_freaking_in_source_build_under_any_circumstances or however we gonna call it, and we need that first. There has been wasted enough time with in-source builds, missing cleanups and all the weird side effects in our industry for decades, and sadly CMake hasn't stopped that nonsense entirely. There are still projects out there that can only build this way because they do some assumptions on where to pick up files, but for something that will end up mixed cross/host build this will never under any circumstances going to work. I wonder if we can't just add it as extra argument to cmake_minimum_required(), in a way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you require a version newer than say 3.14, so anyone that is not explicitely requesting this to work will automagically end up in a "clean" setup. Of course we need to make sure that no file is written by CMake until that line is parsed (or any other command is encountered). Or simply do something similar when using toolchain files, which CMake can detect before even start parsing the main CMakeLists.txt. Eike From eric.noulard at gmail.com Tue Dec 11 09:37:04 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 11 Dec 2018 15:37:04 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> <4054095.oukdIuTTYd@daneel.sf-tec.de> Message-ID: Le mar. 11 d?c. 2018 ? 14:18, Rolf Eike Beer a ?crit : > Eric Noulard wrote: > > > 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". > > I guess putting the host-build location in the toolchain file could be > one way > to just get it done. In case one has multiple builds that should share > one host > build then just set an absolute location, and if you don't it will be > below your > normal build directory. > Yes that seems a reasonable way to do it. There are just 2 things that scare me a bit off: we surely want a way to > break > that into smaller pieces so we can introduce it over multiple releases, > maybe even > as a tech-preview so we can break things if we see that we have not > taken a bigger > usecase in account, and I currently don't see the points to slice that > up. > We could add new builtin command along with an enable_preview command that would bring the currently in preview commands. If you don't call enable_preview CMake will issue an error telling that the command you are trying to are in "preview" if it's the case. When enabling preview you'll get the "in-preview" command plus a warning telling you that enabling preview brings you command/features that are not guaranteed to be backward compatible. Equipped with that we could incubate a feature and switch it from preview to prime-time when we are confident about it. > And we really, really want a > .cmake_no_freaking_in_source_build_under_any_circumstances > or however we gonna call it, and we need that first. There has been > wasted enough time > with in-source builds, missing cleanups and all the weird side effects > in our industry > for decades, and sadly CMake hasn't stopped that nonsense entirely. > There are still > projects out there that can only build this way because they do some > assumptions on > where to pick up files, but for something that will end up mixed > cross/host build this > will never under any circumstances going to work. > Yeah you are damn right, and guess what, I was convinced by that near a decade ago from now https://cmake.org/Bug/view.php?id=6672 !! The old ticket got reloaded in the "new" tracker as https://gitlab.kitware.com/cmake/cmake/issues/6672 > I wonder if we can't just add it as extra argument to > cmake_minimum_required(), in a > way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you > require a version > newer than say 3.14, so anyone that is not explicitely requesting this > to work will > automagically end up in a "clean" setup. Of course we need to make sure > that no file is > written by CMake until that line is parsed (or any other command is > encountered). Or > simply do something similar when using toolchain files, which CMake can > detect before > even start parsing the main CMakeLists.txt. > There is two problems here. 1) AFAIR (there is some discussion about that in the old ticket) as soon as CMake is parsing CMakeLists.txt it creates the CMakeCache.txt and you want to avoid polluting the source before that thus the proposal from Ben & Brad to add the no-in-source enforcement in an extra file. 2) Changing the default behavior of not accepting in-source is good for me but it is clearly backward incompatible. Unless I'm wrong there has not been any such backward-incompatible change in CMake as of now. I doubt this would be widely accepted. Or may be for CMake 4. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Wed Dec 12 07:01:41 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Wed, 12 Dec 2018 13:01:41 +0100 Subject: [cmake-developers] Test for list size Message-ID: <47082E3A-B563-47A0-A64A-A143AC8883D1@Robitzki.de> Hi, we have often the need to test for a minimum list size list(LENGTH list list_size) if (list_size GREATER 1) ? This happens so much, that we though it might be helpful to extend the if-syntax to allow this to be written in a more compact way. For example: if (LENGTH list GREATER 1) ? Or maybe by introducing functions that can return values (length being a ?function? here): if (length[list] GREATER 1) ? What do you think? Are we the only ones that could make good use out of this extension? best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From eike at sf-mail.de Wed Dec 12 07:15:37 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 12 Dec 2018 13:15:37 +0100 Subject: [cmake-developers] Slowdown of nightly builds Message-ID: <1578196.hGo2TcV8Or@devpool21> I noticed that for a few weeks the builds on my machines now take much longer to complete, without any particular change in my setup. This affects 2 different machines, which makes me even more think it's a change in the test suite. Is that something that is expected or is just someone using bootstrapping as a testbed for ExternalProject_Add with 5 runs in parallel? I don't mind if it's something really needed, but if it is just burning cycles than I would like to cut that down to the level before. Today my gcc7 build took 45 minutes test time while it took only 28 minutes before. The change in the dashboard can be seen on the dashboard between 2018-11-09 and 2018-11-10. There was no update in the system CMake version on that day either. Any ideas? By the way: >3 minutes of configure time for CMake looks also quite excessive to me, but that has been the way before, too. Eike From brad.king at kitware.com Wed Dec 12 07:51:48 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 12 Dec 2018 07:51:48 -0500 Subject: [cmake-developers] Slowdown of nightly builds In-Reply-To: <1578196.hGo2TcV8Or@devpool21> References: <1578196.hGo2TcV8Or@devpool21> Message-ID: <1be8b6eb-3546-1b57-b13f-17d9f1941e42@kitware.com> On 12/12/18 7:15 AM, Rolf Eike Beer wrote: > I noticed that for a few weeks the builds on my machines now take much longer > to complete, without any particular change in my setup. > The change in the dashboard can be seen on the dashboard between > 2018-11-09 and 2018-11-10. Thanks! I had noticed that on several machines too but had not found a specific day. This is due to a major performance regression. I've narrowed the problem further and opened an issue: https://gitlab.kitware.com/cmake/cmake/issues/18700 -Brad From brad.king at kitware.com Wed Dec 12 07:54:05 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 12 Dec 2018 07:54:05 -0500 Subject: [cmake-developers] Test for list size In-Reply-To: <47082E3A-B563-47A0-A64A-A143AC8883D1@Robitzki.de> References: <47082E3A-B563-47A0-A64A-A143AC8883D1@Robitzki.de> Message-ID: <8dd94df4-7574-8f03-5935-3a17239efd3b@kitware.com> On 12/12/18 7:01 AM, Torsten Robitzki wrote: > we have often the need to test for a minimum list size > > list(LENGTH list list_size) > if (list_size GREATER 1) > > This happens so much I've almost never needed to test the length of a list. What are you trying to do? -Brad From robert.maynard at kitware.com Wed Dec 12 14:27:11 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Dec 2018 14:27:11 -0500 Subject: [cmake-developers] [ANNOUNCE] cmake.org, gitlab.kitware.com, dashboard downtime Message-ID: Cmake Devs, Kitware NY is moving into a new office building on Dec 15th. This involves moving the company's network and testing infrastructure. As a result, there will be downtime for dashboard machines starting on Dec 13th, and websites starting on Dec 15th. Expect cmake.org, cmake.org/cmake/help/, open.cdash.org, and gitlab.kitware.com to be unavailable all day Dec. 15th while we physically move everything and complete the network cutover. Expect dashboards to start coming online on Dec 17th. There is a good chance of network connectivity being unstable for a few days afterwards while we troubleshoot and fix any issues. From robert.maynard at kitware.com Thu Dec 13 09:11:24 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 13 Dec 2018 09:11:24 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.2 available for download Message-ID: We are pleased to announce that CMake 3.13.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * CMake 3.13.0 included a change to pass compiler implicit include directories to the "moc" tool for "AUTOMOC". This has been reverted due to regressing existing builds and will need further investigation before being re-introduced in a later release. Thanks for your support! ------------------------------------------------------------------------- Changes in 3.13.2 since 3.13.1: Anton Chernov (1): CUDA: Add CUDA 10 (Turing) detection Brad King (2): CUDA: Fix crash on linking to a CUDA target without CUDA enabled CMake 3.13.2 Nils Gladitz (1): CPack/External: Fix status messages of staging scripts Sebastian Holtermann (1): Autogen: Revert passing compiler implicit includes to moc From kyle.edwards at kitware.com Mon Dec 17 15:18:39 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 17 Dec 2018 15:18:39 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support Message-ID: <1545077919.2463.20.camel@kitware.com> Hello everyone, One of the things that's long been requested of CMake is the ability to have multiple toolchains - for instance, one host toolchain and one cross toolchain, so that "utilities" needed for build can be built with the host toolchain and then the "real" software can be built with the cross toolchain. To solve this problem, I would like to propose the creation of a new first-class object type, the "toolchain" type, which would replace the current variable-based system, similar to how imported targets replaced variable-based usage requirements. Every project would automatically receive one toolchain, the "DEFAULT" toolchain, which would be either automatically configured or configured based on CMAKE_TOOLCHAIN_FILE, just like the current system. New toolchains could be added with the add_toolchain() command: add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake) Then, executables and libraries could have a toolchain specified: add_executable(BuildUtility TOOLCHAIN DEFAULT ...) add_library(MyLibrary TOOLCHAIN CrossToolchain ...) Note that the TOOLCHAIN argument is optional, and if omitted, the DEFAULT toolchain is used. If a project uses multiple toolchains, we could have the option to rename the default toolchain with an alternative add_toolchain() syntax: add_toolchain(HostToolchain DEFAULT) Rather than adding a new toolchain, this would simply rename the "DEFAULT" toolchain to "HostToolchain". Then the toolchain specification for each target could look like this: add_executable(BuildUtility TOOLCHAIN HostToolchain ...) add_library(MyLibrary TOOLCHAIN CrossToolchain ...) Two new global read-only properties would be added: TOOLCHAINS and DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of the DEFAULT toolchain (which could be changed with the alternative add_toolchain() syntax.) The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than setting variables: set(CMAKE_C_COMPILER /usr/bin/gcc) set(CMAKE_C_COMPILER_ID gnu) # etc. it would instead set properties on the selected toolchain: set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER /usr/bin/gcc) set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER_ID gnu) # etc. where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain file either at the root or by the add_toolchain() command. If you want to read the value of C_COMPILER, etc. then just use get_property(): get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER) Obviously this system would scale well to more than just two toolchains - just use as many add_toolchain() commands as you need. Backwards compatibility is going to be a challenge. Both the toolchain file and the project have to be aware of the new toolchain system, which means we have to handle four permutations: 1) old toolchain + old project 2) old toolchain + new project 3) new toolchain + old project 4) new toolchain + new project I propose adding a policy that both the toolchain file and the project can set separately, and which would have a slightly different meaning in each one. If the toolchain is OLD and the project is NEW, then the variables set by the toolchain file would be converted into properties on the toolchain for the project. If the toolchain is NEW and the project is OLD, then the properties on the toolchain would be converted into variables in the project. If both the toolchain and project have the same value, then no special conversion is required. I would welcome everyone's feedback on this proposal. Obviously this is a big change to how CMake handles toolchains, and would require a lot of very deep refactoring. Kyle From eric.noulard at gmail.com Mon Dec 17 16:04:04 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 17 Dec 2018 22:04:04 +0100 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545077919.2463.20.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> Message-ID: Hi Kyle, Is your proposal a follow-up on the initial bunch of ideas launched in this thread launch by Eike in November https://cmake.org/pipermail/cmake-developers/2018-November/030913.html with follow-up ideas in in december: https://cmake.org/pipermail/cmake-developers/2018-December/030920.html or is it somehow unrelated? Le lun. 17 d?c. 2018 ? 21:18, Kyle Edwards via cmake-developers < cmake-developers at cmake.org> a ?crit : > Hello everyone, > > One of the things that's long been requested of CMake is the ability to > have multiple toolchains - for instance, one host toolchain and one > cross toolchain, so that "utilities" needed for build can be built with > the host toolchain and then the "real" software can be built with the > cross toolchain. > > To solve this problem, I would like to propose the creation of a new > first-class object type, the "toolchain" type, which would replace the > current variable-based system, similar to how imported targets replaced > variable-based usage requirements. > > Every project would automatically receive one toolchain, the "DEFAULT" > toolchain, which would be either automatically configured or configured > based on CMAKE_TOOLCHAIN_FILE, just like the current system. New > toolchains could be added with the add_toolchain() command: > > add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake) > This has some common design issue as my proposal: enable_cross_target(...) for which Eike has valuable doubt: https://cmake.org/pipermail/cmake-developers/2018-November/030919.html > Then, executables and libraries could have a toolchain specified: > > add_executable(BuildUtility TOOLCHAIN DEFAULT ...) > add_library(MyLibrary TOOLCHAIN CrossToolchain ...) > > Note that the TOOLCHAIN argument is optional, and if omitted, the > DEFAULT toolchain is used. > So if you want to build both for host and cross toolchain you'll have to explicitely add_executable/library(MyLibrary TOOLCHAIN DEFAULT) add_executable/library(MyLibrary TOOLCHAIN CrossToolchain) If you follow the previously referred discussion you cannot assume that one lib/exe built for a toolchain is not built for another toolchain as well. How do you envision the cross-toolchain target dependency which was a question raised several time. > If a project uses multiple toolchains, we could have the option to > rename the default toolchain with an alternative add_toolchain() > syntax: > > add_toolchain(HostToolchain DEFAULT) > > Rather than adding a new toolchain, this would simply rename the > "DEFAULT" toolchain to "HostToolchain". Then the toolchain > specification for each target could look like this: > > add_executable(BuildUtility TOOLCHAIN HostToolchain ...) > add_library(MyLibrary TOOLCHAIN CrossToolchain ...) > > Two new global read-only properties would be added: TOOLCHAINS and > DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of > all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of > the DEFAULT toolchain (which could be changed with the alternative > add_toolchain() syntax.) > > The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than > setting variables: > > set(CMAKE_C_COMPILER /usr/bin/gcc) > set(CMAKE_C_COMPILER_ID gnu) > # etc. > > it would instead set properties on the selected toolchain: > > set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER > /usr/bin/gcc) > set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY > C_COMPILER_ID gnu) > # etc. > I don't see why we should change the syntax of current toolchain file, I don't see the benefit. CMake already knows when (and which) toolchain file is loaded and it could perfectly automatically > > where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain > file either at the root or by the add_toolchain() command. > > If you want to read the value of C_COMPILER, etc. then just use > get_property(): > > get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER) > > Obviously this system would scale well to more than just two toolchains > - just use as many add_toolchain() commands as you need. > > Backwards compatibility is going to be a challenge. Both the toolchain > file and the project have to be aware of the new toolchain system, > which means we have to handle four permutations: > > 1) old toolchain + old project > 2) old toolchain + new project > 3) new toolchain + old project > 4) new toolchain + new project > > I propose adding a policy that both the toolchain file and the project > can set separately, and which would have a slightly different meaning > in each one. If the toolchain is OLD and the project is NEW, then the > variables set by the toolchain file would be converted into properties > on the toolchain for the project. If the toolchain is NEW and the > project is OLD, then the properties on the toolchain would be converted > into variables in the project. If both the toolchain and project have > the same value, then no special conversion is required. > > I would welcome everyone's feedback on this proposal. Obviously this is > a big change to how CMake handles toolchains, and would require a lot > of very deep refactoring. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 17 16:06:33 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 17 Dec 2018 22:06:33 +0100 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> Message-ID: Le lun. 17 d?c. 2018 ? 22:04, Eric Noulard a ?crit : > Hi Kyle, > > Is your proposal a follow-up on the initial bunch of ideas launched in > this thread launch by Eike in November > https://cmake.org/pipermail/cmake-developers/2018-November/030913.html > with follow-up ideas in in december: > https://cmake.org/pipermail/cmake-developers/2018-December/030920.html > > or is it somehow unrelated? > > > Le lun. 17 d?c. 2018 ? 21:18, Kyle Edwards via cmake-developers < > cmake-developers at cmake.org> a ?crit : > >> Hello everyone, >> >> One of the things that's long been requested of CMake is the ability to >> have multiple toolchains - for instance, one host toolchain and one >> cross toolchain, so that "utilities" needed for build can be built with >> the host toolchain and then the "real" software can be built with the >> cross toolchain. >> >> To solve this problem, I would like to propose the creation of a new >> first-class object type, the "toolchain" type, which would replace the >> current variable-based system, similar to how imported targets replaced >> variable-based usage requirements. >> >> Every project would automatically receive one toolchain, the "DEFAULT" >> toolchain, which would be either automatically configured or configured >> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New >> toolchains could be added with the add_toolchain() command: >> >> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake) >> > > This has some common design issue as my proposal: > enable_cross_target(...) > for which Eike has valuable doubt: > https://cmake.org/pipermail/cmake-developers/2018-November/030919.html > > >> Then, executables and libraries could have a toolchain specified: >> >> add_executable(BuildUtility TOOLCHAIN DEFAULT ...) >> add_library(MyLibrary TOOLCHAIN CrossToolchain ...) >> >> Note that the TOOLCHAIN argument is optional, and if omitted, the >> DEFAULT toolchain is used. >> > > So if you want to build both for host and cross toolchain you'll have to > explicitely > add_executable/library(MyLibrary TOOLCHAIN DEFAULT) > add_executable/library(MyLibrary TOOLCHAIN CrossToolchain) > > If you follow the previously referred discussion you cannot assume that > one lib/exe > built for a toolchain is not built for another toolchain as well. > > How do you envision the cross-toolchain target dependency which was > a question raised several time. > > >> If a project uses multiple toolchains, we could have the option to >> rename the default toolchain with an alternative add_toolchain() >> syntax: >> >> add_toolchain(HostToolchain DEFAULT) >> >> Rather than adding a new toolchain, this would simply rename the >> "DEFAULT" toolchain to "HostToolchain". Then the toolchain >> specification for each target could look like this: >> >> add_executable(BuildUtility TOOLCHAIN HostToolchain ...) >> add_library(MyLibrary TOOLCHAIN CrossToolchain ...) >> >> Two new global read-only properties would be added: TOOLCHAINS and >> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of >> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of >> the DEFAULT toolchain (which could be changed with the alternative >> add_toolchain() syntax.) >> >> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than >> setting variables: >> >> set(CMAKE_C_COMPILER /usr/bin/gcc) >> set(CMAKE_C_COMPILER_ID gnu) >> # etc. >> >> it would instead set properties on the selected toolchain: >> >> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER >> /usr/bin/gcc) >> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY >> C_COMPILER_ID gnu) >> # etc. >> > > I don't see why we should change the syntax of current toolchain file, I > don't see the benefit. > CMake already knows when (and which) toolchain file is loaded and it could > perfectly automatically > ... sorry wrong key pressed... CMake could perfectly automatically create the new "TOOLCHAIN" object by loading the very same toolchain file as we have today. We could simple add a new variable CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name them as he wants. When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Mon Dec 17 16:54:44 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 17 Dec 2018 16:54:44 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> Message-ID: <1545083684.2463.28.camel@kitware.com> Eric, Thanks for the feedback. See comments below. On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote: > > This has some common design issue as my proposal: > > enable_cross_target(...) > > for which Eike has valuable doubt: > > https://cmake.org/pipermail/cmake-developers/2018-November/030919.h > > tml? If you're talking about the issue of specifying multiple toolchain files on the command line, I'm imagining a design like this: add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET}) and then specify it on the command line with: cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake -DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake > > So if you want to build both for host and cross toolchain you'll have to explicitely? > > add_executable/library(MyLibrary TOOLCHAIN DEFAULT) > > add_executable/library(MyLibrary TOOLCHAIN CrossToolchain) > > > > If you follow the previously referred discussion you cannot assume that one lib/exe > > built for a toolchain is not built for another toolchain as well. If you want to build the same target with multiple toolchains then I think you're better off declaring them as different targets, with different TOOLCHAINs but the same source files, etc. > > ... sorry wrong key pressed... > > > > CMake could perfectly automatically create the new "TOOLCHAIN" object by loading the very > > same toolchain file as we have today. We could simple add a new variable > > CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name them as he wants. > > When there is no CMAKE_TOOLCHAIN_NAME this would be the default > > toolchain. > My vision for this feature is that the project specifies the names of the toolchains that it's expecting, and the toolchain file is agnostic of this - it simply sets the properties of the toolchain named ${CMAKE_SELECTED_TOOLCHAIN}. If you want to have a variable number of toolchains, you could do something like this: set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of toolchains") foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES}) ? add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}}) ? add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for each target platform endforeach() Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Tue Dec 18 06:14:28 2018 From: frodak17 at gmail.com (frodak17) Date: Tue, 18 Dec 2018 06:14:28 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545083684.2463.28.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> Message-ID: What first cross my mind with '"utilities" needed for build' is when you have to build the cross-compiler in the first place before you build anything for the target. If so how do you handle verification of the tool-chain can build a working executable or library? Normally that is done at the time before project files are generated but it has to either be skipped or delayed because the toolchain doesn't even exist because it has to be built first by the host tools. For tool-chains that already exist on the host machine then add_toolchain() command is when you can test and verify its functionality? So if you want to build both for host and cross toolchain you'll have to >> explicitely >> add_executable/library(MyLibrary TOOLCHAIN DEFAULT) >> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain) >> > Do these targets automatically get separate binary directories so that the outputs don't overwrite each other? I assume this feature is limited only to ninja or makefile generators? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Dec 18 09:34:00 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 18 Dec 2018 09:34:00 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> Message-ID: <1545143640.2463.40.camel@kitware.com> On Tue, 2018-12-18 at 06:14 -0500, frodak17 wrote: > What first cross my mind with '"utilities" needed for build' is when > you have to build the cross-compiler in the first place before you > build anything for the target. > If so how do you handle verification of the tool-chain can build a > working executable or library? > Normally that is done at the time before project files are generated > but it has to either be skipped or delayed because the toolchain > doesn't even exist because it has to be built first by the host > tools. For tool-chains that already exist on the host machine then > add_toolchain() command is when you can test and verify its > functionality? Yes, add_toolchain() would do all the same checks that happen on the "main" toolchain when CMake starts up. The process would be: 1) add_toolchain() gets called with a FILE argument 2) the file gets loaded the same way CMAKE_TOOLCHAIN_FILE does on startup 3) CMake performs all the same checks that it did with the "main" toolchain 4) add_toolchain() returns and script execution resumes So you could build the cross toolchain during configure-time and then add it with add_toolchain(). However, I would recommend having the toolchain build and the actual project be separate CMake projects in order to maintain separation of responsibilities. At the very least, I'd recommend that the cross-compiled project be a subdirectory of the superbuild via add_subdirectory(), and the toolchain would be built in the top directory. > Do these targets automatically get separate binary directories so > that the outputs don't overwrite each other? No. In this feature, each target would get one toolchain, and *only* one toolchain. If you want to build the same target with multiple toolchains, you would build them as separate targets. Example: add_executable(foo-arm foo.c bar.c TOOLCHAIN ArmToolchain) add_executable(foo-x86_64 foo.c bar.c TOOLCHAIN x86_64Toolchain) This could of course be abstracted away with a function(): function(make_foo toolchain) ? add_executable(foo-${toolchain} foo.c bar.c TOOLCHAIN ${toolchain}) endfunction() make_foo(arm) make_foo(x86_64) My reasoning for this is that each .c/.cxx file has to be built multiple times (once for each toolchain) anyway, so why bother trying to make them part of the same target? Just make them separate targets. > I assume this feature is limited only to ninja or makefile > generators? If Visual Studio and/or Xcode support multiple toolchains (I don't know if they do) then it could work for them too. If not then they would unfortunately be out of luck for multi-toolchain projects. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Tue Dec 18 14:10:12 2018 From: frodak17 at gmail.com (frodak17) Date: Tue, 18 Dec 2018 14:10:12 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545143640.2463.40.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> Message-ID: How does this work with multiple languages and the project() command and enable_language() commands? For instance you want to use the host c++ compiler and a toolchain specified compiler for c and c++. When project() enables the c++ compiler it runs through a bunch of scripts to find and test the compiler also setting several CMAKE__* variables to use that compiler. These variables also happen to be the default compile options for the build types when using that compiler. Then the same thing happens with the tool-chain specified compiler for these languages how do you track that the variables are different for these two toolchains? Are these variables now project scoped and for any given project it is limited to one toolchain per language per project? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Dec 18 14:56:35 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 18 Dec 2018 14:56:35 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> Message-ID: <1545162995.2463.50.camel@kitware.com> On Tue, 2018-12-18 at 14:10 -0500, frodak17 wrote: > How does this work with multiple languages and the project() command > and enable_language() commands? Both project() and enable_language() could be extended with an optional TOOLCHAIN argument. > For instance you want to use the host c++ compiler and a toolchain > specified compiler for c and c++. > When project() enables the c++ compiler it runs through a bunch of scripts to find and test the compiler also setting several CMAKE__* variables to use that compiler.? These variables also happen to be the default compile options for the build types when using that compiler. The point of this idea is to get rid of the old variable-based system and have everything instead be a property of a toolchain. So the scripts would set properties of the default toolchain instead of setting variables. > Then the same thing happens with the tool-chain specified compiler > for these languages how do you track that the variables are different > for these two toolchains? > Are these variables now project scoped and for any given project it > is limited to one toolchain per language per project? > See above. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Tue Dec 18 16:12:37 2018 From: frodak17 at gmail.com (frodak17) Date: Tue, 18 Dec 2018 16:12:37 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545162995.2463.50.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> Message-ID: > How does this work with multiple languages and the project() command and >> enable_language() commands? >> > Both project() and enable_language() could be extended with an optional > TOOLCHAIN argument. > So it would be something like project( [TOOLCHAIN [LANGUAGES] [...]) where TOOLCHAIN and its supported languages can be repeated for each tool chain. i.e project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross LANGUAGES c) For instance you want to use the host c++ compiler and a toolchain > specified compiler for c and c++. > When project() enables the c++ compiler it runs through a bunch of scripts > to find and test the compiler also setting several CMAKE__* variables > to use that compiler. These variables also happen to be the default > compile options for the build types when using that compiler. > > > The point of this idea is to get rid of the old variable-based system and > have everything instead be a property of a toolchain. So the scripts would > set properties of the default toolchain instead of setting variables. > > Then the same thing happens with the tool-chain specified compiler for > these languages how do you track that the variables are different for these > two toolchains? > Are these variables now project scoped and for any given project it is > limited to one toolchain per language per project? > > > See above. > But isn't this all (or mostly) cached so you don't have to redo all this when regenerating build files. I guess it would be CMAKE___* ? What about conflicting build types when building a host tool target vs the cross compiler target? For instance the host tool may (should?) be built as a release project (default optimization levels) but the cross compiler project could be built as a debug project (so you can debug it with no optimizations)? I guess it would then be CMAKE__BUILD_TYPE and then targets using that toolchain would be built with that build type. On the other hand this doesn't really help anyone working with mixed build systems. What you can't do in a straight forward manner is host tool development with Visual Studio or Eclipse, execute it and use it's results with a cross compiler (that uses Ninja or Makefiles) targeting an embedded system. In this case I think that what you want is to easily control multiple projects using different build systems, the inter-dependencies, and easily specify that external project A produces a file for external project B. Ideally you would be in the root of the build folder and type 'cmake --build .' and have it take care of everything with minimal extraneous build tool executions or sometimes even invoking the build tool in parallel for external projects that don't depend on each other. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Dec 18 16:41:27 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 18 Dec 2018 16:41:27 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> Message-ID: <1545169287.2463.68.camel@kitware.com> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: > So it would be something like project( [TOOLCHAIN > [LANGUAGES] [...]) where TOOLCHAIN > and its supported languages can be repeated for each tool chain. i.e > project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross > LANGUAGES c) I think this sounds about right. > But isn't this all (or mostly) cached so you don't have to redo all this when regenerating build files. I guess it would be CMAKE___* ? Good point about caching, I did not think of that. Perhaps we need some separate caching mechanism for toolchain properties - or perhaps the properties could be loaded from undocumented cache variables defined only for CMake's internal use. > What about conflicting build types when building a host tool target vs the cross compiler target? > For instance the host tool may (should?) be built as a release project (default optimization levels) but the cross compiler project could be built as a debug project (so you can debug it with no optimizations)? > I guess it would then be CMAKE__BUILD_TYPE and then targets using that toolchain would be built with that build type. I think that both host and cross targets would be built with the same build type. If you're using a multi-config generator like VS or Xcode, how do you specify which combination of configs you want? It's simpler if every target is built as the same type, whether it's host or cross. Think about it - the current system already expects that every target in the project is built as the same build type. There's no way to specify "foo is built as debug, bar is built as release." Why would this assumption change just because we add a multi-toolchain mechanic? > On the other hand this doesn't really help anyone working with mixed build systems.? What you can't do in a straight forward manner is host tool development with Visual Studio or Eclipse, execute it and use it's results with a cross compiler (that uses Ninja or Makefiles) targeting an embedded system. Every target would be built by the same generator regardless of whether it's a host or cross target. So if you select the VS generator, both the host tools and the embedded software would be built in VS (if this is possible.) Likewise for Ninja and Make. > In this case I think that what you want is to easily control multiple > projects using different build systems, the inter-dependencies, and > easily specify that external project A produces a file for external > project B.? Ideally you would be in the root of the build folder and > type 'cmake --build .' and have it take care of everything with > minimal extraneous build tool executions or sometimes even invoking > the build tool in parallel for external projects that don't depend on > each other. > If you want to build different parts of the software with different generators (build systems) then you're better off using a superbuild with ExternalProject. The intent of this proposal is to allow users to build both host tools and cross-compiled software in the same build tree with the same generator. As an example of a real-world project, I would like to emulate the Linux kernel's separation of host and cross compiler. The vast majority of files in the kernel source tree are built with a single cross compiler, while a very small set of host tools are built with the host compiler. Both the host tools and the kernel itself are built using the same Makefile, and there's no ExternalProject-like separation between them. The kernel's buildsystem only supports Makefiles and can't generate Ninja, VS, etc., but if it did, then both the host tools and the kernel would be built with the same Ninja files/VS solution. I don't remember whether it supports building the host tools and kernel as separate types (debug vs release), but for sake of simplicity, I'd rather not try to support that, especially in multi-config generators. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Tue Dec 18 20:53:42 2018 From: frodak17 at gmail.com (frodak17) Date: Tue, 18 Dec 2018 20:53:42 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545169287.2463.68.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> <1545169287.2463.68.camel@kitware.com> Message-ID: On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards wrote: > On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: > > What about conflicting build types when building a host tool target vs the > cross compiler target? > For instance the host tool may (should?) be built as a release project > (default optimization levels) but the cross compiler project could be built > as a debug project (so you can debug it with no optimizations)? > I guess it would then be CMAKE__BUILD_TYPE and then targets > using that toolchain would be built with that build type. > > > I think that both host and cross targets would be built with the same > build type. If you're using a multi-config generator like VS or Xcode, how > do you specify which combination of configs you want? It's simpler if every > target is built as the same type, whether it's host or cross. Think about > it - the current system already expects that every target in the project is > built as the same build type. There's no way to specify "foo is built as > debug, bar is built as release." Why would this assumption change just > because we add a multi-toolchain mechanic? > I have thought about it which is why I asked. The original assumption of one toolchain per CMake project is being extended. So why not think of extending the build type. Sure it's simpler to ignore the build type. However, it doesn't make sense to me to build and run a host tool in debug mode when it could be running faster if built in release mode. This is independent of whatever I'm doing with cross-compiler targets. You're already updating the generator to pick and choose the proper flags just on the tool chain type and it already picks the correct flags based on the configuration type. But instead of the generator looking at the global build type it looks at the target build type. The target build type could default to the global build type and be overridden via a property. Multi config generators would be problematic if they don't have a Configuration Manager that allows for setting different projects with different configurations (like Visual Studio) but is that reason enough to exclude the idea for single configuration generators? > On the other hand this doesn't really help anyone working with mixed build > systems. What you can't do in a straight forward manner is host tool > development with Visual Studio or Eclipse, execute it and use it's results > with a cross compiler (that uses Ninja or Makefiles) targeting an embedded > system. > > > Every target would be built by the same generator regardless of whether > it's a host or cross target. So if you select the VS generator, both the > host tools and the embedded software would be built in VS (if this is > possible.) Likewise for Ninja and Make. > > In this case I think that what you want is to easily control multiple > projects using different build systems, the inter-dependencies, and easily > specify that external project A produces a file for external project B. > Ideally you would be in the root of the build folder and type 'cmake > --build .' and have it take care of everything with minimal extraneous > build tool executions or sometimes even invoking the build tool in parallel > for external projects that don't depend on each other. > > > If you want to build different parts of the software with different > generators (build systems) then you're better off using a superbuild with > ExternalProject. The intent of this proposal is to allow users to build > both host tools and cross-compiled software in the same build tree with the > same generator. > Sure. I was thinking / commenting about the other real world projects that are more complicated. Can add_custom_command() be used to run a binary that was built as an ExternalProject which it was linked via depends to generate a file that is used by several other ExternalProjects and it's all glued together with proper dependencies so it can be invoked by a single command? If this can already be simply done why is anyone asking to use multiple toolchains in a single project? You just use an ExternalProject with each toolchain file and you're done, or is this a shortcut method instead of using ExternalProject to build the host tool? If ExternalProject doesn't define a target that can be used as a dependency for add_custom_command() or add_dependencies() then isn't this a problem which is driving people to ask to use multiple toolchains? https://cmake.org/pipermail/cmake-developers/2018-December/030920.html This email seems to indicate that ExternalProject can't be used with add_custom_command(). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitranopeter at gmail.com Wed Dec 19 00:05:06 2018 From: mitranopeter at gmail.com (Peter Mitrano) Date: Wed, 19 Dec 2018 00:05:06 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> <1545169287.2463.68.camel@kitware.com> Message-ID: Hey all, just thought I would chime in and note that I very often write code that I expect to run both on my robots hardware and on my development machine in a simulator. In this case, I want the same target names and everything -- I simply use two cmake build directories, and now there is even support for this workflow in CLion so my life is very easy. Doing all of those as two targets with distinct names would be cumbersome, and the current system works very well for me. On Tue, Dec 18, 2018 at 8:54 PM frodak17 wrote: > > > On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards > wrote: > >> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: >> >> What about conflicting build types when building a host tool target vs >> the cross compiler target? >> For instance the host tool may (should?) be built as a release project >> (default optimization levels) but the cross compiler project could be built >> as a debug project (so you can debug it with no optimizations)? >> I guess it would then be CMAKE__BUILD_TYPE and then targets >> using that toolchain would be built with that build type. >> >> >> I think that both host and cross targets would be built with the same >> build type. If you're using a multi-config generator like VS or Xcode, how >> do you specify which combination of configs you want? It's simpler if every >> target is built as the same type, whether it's host or cross. Think about >> it - the current system already expects that every target in the project is >> built as the same build type. There's no way to specify "foo is built as >> debug, bar is built as release." Why would this assumption change just >> because we add a multi-toolchain mechanic? >> > > I have thought about it which is why I asked. The original assumption of > one toolchain per CMake project is being extended. So why not think of > extending the build type. Sure it's simpler to ignore the build type. > However, it doesn't make sense to me to build and run a host tool in debug > mode when it could be running faster if built in release mode. This is > independent of whatever I'm doing with cross-compiler targets. You're > already updating the generator to pick and choose the proper flags just on > the tool chain type and it already picks the correct flags based on the > configuration type. But instead of the generator looking at the global > build type it looks at the target build type. The target build type could > default to the global build type and be overridden via a property. > > Multi config generators would be problematic if they don't have a > Configuration Manager that allows for setting different projects with > different configurations (like Visual Studio) but is that reason enough to > exclude the idea for single configuration generators? > >> On the other hand this doesn't really help anyone working with mixed >> build systems. What you can't do in a straight forward manner is host tool >> development with Visual Studio or Eclipse, execute it and use it's results >> with a cross compiler (that uses Ninja or Makefiles) targeting an embedded >> system. >> >> >> Every target would be built by the same generator regardless of whether >> it's a host or cross target. So if you select the VS generator, both the >> host tools and the embedded software would be built in VS (if this is >> possible.) Likewise for Ninja and Make. >> >> In this case I think that what you want is to easily control multiple >> projects using different build systems, the inter-dependencies, and easily >> specify that external project A produces a file for external project B. >> Ideally you would be in the root of the build folder and type 'cmake >> --build .' and have it take care of everything with minimal extraneous >> build tool executions or sometimes even invoking the build tool in parallel >> for external projects that don't depend on each other. >> >> >> If you want to build different parts of the software with different >> generators (build systems) then you're better off using a superbuild with >> ExternalProject. The intent of this proposal is to allow users to build >> both host tools and cross-compiled software in the same build tree with the >> same generator. >> > > Sure. I was thinking / commenting about the other real world projects > that are more complicated. Can add_custom_command() be used to run a > binary that was built as an ExternalProject which it was linked via depends > to generate a file that is used by several other ExternalProjects and it's > all glued together with proper dependencies so it can be invoked by a > single command? > > If this can already be simply done why is anyone asking to use multiple > toolchains in a single project? You just use an ExternalProject with each > toolchain file and you're done, or is this a shortcut method instead of > using ExternalProject to build the host tool? > > If ExternalProject doesn't define a target that can be used as a > dependency for add_custom_command() or add_dependencies() then isn't this a > problem which is driving people to ask to use multiple toolchains? > > https://cmake.org/pipermail/cmake-developers/2018-December/030920.html > > This email seems to indicate that ExternalProject can't be used with > add_custom_command(). > -- > > 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: From wouter.klouwen at youview.com Wed Dec 19 14:16:12 2018 From: wouter.klouwen at youview.com (Wouter Klouwen) Date: Wed, 19 Dec 2018 19:16:12 +0000 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> <1545169287.2463.68.camel@kitware.com> Message-ID: <70c47b5a-d793-704a-3752-d8cb4d3b66d2@youview.com> Hello, just chiming in here. I work for a company that works with embedded devices, so cross compiling is our bread and butter. We have a super build system - in a combination of CMake and Makefile - that first builds a certain set of projects for the host platform and second builds for the actual target platform. For testing purposes we can also build all projects for the host platform to run tests. All of the projects are compiled through ExternalProject, as it's a mix of open source packages which can use arbitrary build systems and our own projects, which use CMake. Within our own projects we already have a set of functions that wrap add_executable() and add_library() to make our lives easier and enforce common idioms so adding some multiple toolchains there would be easy. The open source packages would be a bit trickier as we'd have to ensure that with the ExternalProject calls it would use the correct toolchain given a CMake toolchain definition that would then have to apply to a non CMake build system such as automake. However, we don't just have one target platform, we have more than 5 combined ARM and MIPS platforms all with different gcc versions, etc, along with the host build. Each different platform may have a different set of projects enabled. This depends on a great number of variables, like hardware support, etc., as well as non technical reasons. If there was multiple toolchain support, we could squash the super build system away which gives a bit more of an integrated system - great - but the complexity of selecting the correct projects to build given a certain platform would then have to be put somewhere else - not so great. While I dislike the super build system concept, it does provide for an abstraction of that complexity for some of these problems. As we have adopted CMake wider and wider over the past few months, some of the limitations have become clearer too, mainly the fact it runs on a single thread. We have over 400 individual projects with nearly 1000 CMakeLists.txt files with a total of 27k lines of CMake. I have performed some experiments to partially convert the super build system to be purely CMake for the single stages, which was an interesting exercise. I found that the process from parsing the CMake files to generating the 50MB worth of build.ninja file took over 30 seconds on an i7 CPU with SATA SSDs. If this was further extended to include both host and target that would result in an even slower build file generation. The super build system concept helps us here too as by splitting the parsing of CMakeLists.txt up with ExternalProject the overall generation of the build.ninja file takes a "mere" ~7 seconds. This limitation alone means that doing any of this could be really detrimental to the iterative build cycle and would severely limit the usability of this feature for us. W On 19/12/2018 05:05, Peter Mitrano wrote: > [External email] > > Hey all, just thought I would chime in and note that I very often write > code that I expect to run both on my robots hardware and on my > development machine in a simulator. In this case, I want the same target > names and everything -- I simply use two cmake build directories, and > now there is even support for this workflow in CLion so my life is very > easy. Doing all of those as two targets with distinct names would be > cumbersome, and the current system works very well for me. > > On Tue, Dec 18, 2018 at 8:54 PM frodak17 > wrote: > > > > On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards > > wrote: > > On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: >> What about conflicting build types when building a host tool >> target vs the cross compiler target? >> For instance the host tool may (should?) be built as a release >> project (default optimization levels) but the cross compiler >> project could be built as a debug project (so you can debug it >> with no optimizations)? >> I guess it would then be CMAKE__BUILD_TYPE and then >> targets using that toolchain would be built with that build type. > > I think that both host and cross targets would be built with the > same build type. If you're using a multi-config generator like > VS or Xcode, how do you specify which combination of configs you > want? It's simpler if every target is built as the same type, > whether it's host or cross. Think about it - the current system > already expects that every target in the project is built as the > same build type. There's no way to specify "foo is built as > debug, bar is built as release." Why would this assumption > change just because we add a multi-toolchain mechanic? > > > I have thought about it which is why I asked. The original > assumption of one toolchain per CMake project is being extended. So > why not think of extending the build type. Sure it's simpler to > ignore the build type. However, it doesn't make sense to me to build > and run a host tool in debug mode when it could be running faster if > built in release mode. This is independent of whatever I'm doing > with cross-compiler targets. You're already updating the generator > to pick and choose the proper flags just on the tool chain type and > it already picks the correct flags based on the configuration type. > But instead of the generator looking at the global build type it > looks at the target build type. The target build type could default > to the global build type and be overridden via a property. > > Multi config generators would be problematic if they don't have a > Configuration Manager that allows for setting different projects > with different configurations (like Visual Studio) but is that > reason enough to exclude the idea for single configuration generators? > >> On the other hand this doesn't really help anyone working with >> mixed build systems. What you can't do in a straight forward >> manner is host tool development with Visual Studio or Eclipse, >> execute it and use it's results with a cross compiler (that >> uses Ninja or Makefiles) targeting an embedded system. > > Every target would be built by the same generator regardless of > whether it's a host or cross target. So if you select the VS > generator, both the host tools and the embedded software would > be built in VS (if this is possible.) Likewise for Ninja and Make. > >> In this case I think that what you want is to easily control >> multiple projects using different build systems, the >> inter-dependencies, and easily specify that external project A >> produces a file for external project B. Ideally you would be >> in the root of the build folder and type 'cmake --build .' and >> have it take care of everything with minimal extraneous build >> tool executions or sometimes even invoking the build tool in >> parallel for external projects that don't depend on each other. > > If you want to build different parts of the software with > different generators (build systems) then you're better off > using a superbuild with ExternalProject. The intent of this > proposal is to allow users to build both host tools and > cross-compiled software in the same build tree with the same > generator. > > > Sure. I was thinking / commenting about the other real world > projects that are more complicated. Can add_custom_command() be > used to run a binary that was built as an ExternalProject which it > was linked via depends to generate a file that is used by several > other ExternalProjects and it's all glued together with proper > dependencies so it can be invoked by a single command? > > If this can already be simply done why is anyone asking to use > multiple toolchains in a single project? You just use an > ExternalProject with each toolchain file and you're done, or is this > a shortcut method instead of using ExternalProject to build the host > tool? > > If ExternalProject doesn't define a target that can be used as a > dependency for add_custom_command() or add_dependencies() then isn't > this a problem which is driving people to ask to use multiple > toolchains? > > https://cmake.org/pipermail/cmake-developers/2018-December/030920.html > > This email seems to indicate that ExternalProject can't be used with > add_custom_command(). > -- > > 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 > > > > [External email. Treat hyperlinks and attachments with caution] > > This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com From kyle.edwards at kitware.com Wed Dec 19 14:25:58 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 19 Dec 2018 14:25:58 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> <1545083684.2463.28.camel@kitware.com> <1545143640.2463.40.camel@kitware.com> <1545162995.2463.50.camel@kitware.com> <1545169287.2463.68.camel@kitware.com> Message-ID: <1545247558.2463.91.camel@kitware.com> On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote: > I have thought about it which is why I asked.? The original > assumption of one toolchain per CMake project is being extended. So > why not think of extending the build type.? Sure it's simpler to > ignore the build type. However, it doesn't make sense to me to build > and run a host tool in debug mode when it could be running faster if > built in release mode.? This is independent of whatever I'm doing > with cross-compiler targets. You're already updating the generator to > pick and choose the proper flags just on the tool chain type and it > already picks the correct flags based on the configuration type.? But > instead of the generator looking at the global build type it looks at > the target build type. The target build type could default to the > global build type and be overridden via a property. > > Multi config generators would be problematic if they don't have a > Configuration Manager that allows for setting different projects with > different configurations (like Visual Studio) but is that reason > enough to exclude the idea for single configuration generators? I suppose we could consider the idea of supporting this separation for single-config generators, but I can't think of a good way to make it work for multi-config generators. > If this can already be simply done why is anyone asking to use multiple toolchains in a single project?? You just use an ExternalProject with each toolchain file and you're done, or is this a shortcut method instead of using ExternalProject to build the host tool? You can use ExternalProject, but it's a bit like using a chainsaw when all you need is a scalpel. Multi-toolchain would make it easy to keep host tools and target code in the same project in the *simple* case (like the Linux kernel example I gave in a previous email.) If you want to do something more complicated then ExternalProject would be your best bet. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivamprettimn at gmail.com Fri Dec 21 13:50:57 2018 From: ivamprettimn at gmail.com (Ivam Pretti) Date: Fri, 21 Dec 2018 13:50:57 -0500 Subject: [cmake-developers] cmake-developers Digest, Vol 122, Issue 9 In-Reply-To: References: Message-ID: happy birthday! Em ter, 11 de set de 2018 ?s 11:00, escreveu: > Send cmake-developers mailing list submissions to > cmake-developers at cmake.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://cmake.org/mailman/listinfo/cmake-developers > or, via email, send a message with subject or body 'help' to > cmake-developers-request at cmake.org > > You can reach the person managing the list at > cmake-developers-owner at cmake.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cmake-developers digest..." > > > Today's Topics: > > 1. Re: [CMake] Happy Birthday CMake! (Bill Hoffman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Sep 2018 13:36:56 -0400 > From: Bill Hoffman > To: "Alan W. Irwin" > Cc: CMake Mailinglist , cmake-developers at cmake.org > Subject: Re: [cmake-developers] [CMake] Happy Birthday CMake! > Message-ID: <8f57ddd0-2363-8ac2-cbab-62f35edb118b at kitware.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 9/2/2018 6:54 PM, Alan W. Irwin wrote: > > > > And thanks to you for coming up with such a useful tool in the first > > place! > > > > Can you recommend a site that gives a (fairly) short history of CMake > > that at least lists the most fundamental changes made to this software > > since its inception?? For example, I am pretty sure you have stated > > before that it > > did not start out as a C++ project.? If so, when did it switch to C++? > > I did look at , but the history > > paragraph there includes nothing about the fundamental changes made along > > the way in the development of CMake. > CMake has always been in C++.?? The idea was that all that would be > required would be a C++ compiler.? With that, you could build CMake.? > Since CMake was designed to build C++ projects, it was assumed that the > user would at least have a C++ compiler. > > Should be some history these talks: > https://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata > https://www.youtube.com/watch?v=TqjtN8NGtl4 > > I don't think there is anything written. > > -Bill > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://cmake.org/pipermail/cmake-developers/attachments/20180910/12b3250c/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > -- > > 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 > > > ------------------------------ > > End of cmake-developers Digest, Vol 122, Issue 9 > ************************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Sat Dec 22 10:57:36 2018 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Sat, 22 Dec 2018 16:57:36 +0100 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545077919.2463.20.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> Message-ID: Hi, > Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers : > > Then, executables and libraries could have a toolchain specified: > > add_executable(BuildUtility TOOLCHAIN DEFAULT ...) > add_library(MyLibrary TOOLCHAIN CrossToolchain ?) or even toolchains: add_library(feature1 TOOLCHAINS CrossToolChain HostToolChain) add_executable(Firmware TOOLCHAIN CrossToolChain) target_link_libraries(Firmware feature1) add_executable(Test_Feature1 TOOLCHAIN HostToolChain) target_link_libraries(Test_Feature1 feature1) A nice feature would be to let toolchain propagate along the dependency graph defined by `target_link_libraries`. So in the example above, the TOOLCHAINS option to `add_library` would be optional, because the target Firmware requires feature1 to be build with CrossToolChain and Test_Feature1 to be build with HostToolChain. Which requires the build to have different binary directories for every toolchain. (Which for me is an indication that having multidimensional build types would be the more natural way to go) What I?m still missing is support to define dependencies between different targets (build by different toolchains), so that I can describe that I require a tool that is build with the HostToolChain, to generate a file that is required by the part of the build, that is using the CrossToolChain. And, of cause, if the source of that tool changes, that tool have to be rebuild and the generated file from the CrossToolChain part of the build have to be rebuild. best regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kyle.edwards at kitware.com Mon Dec 24 11:07:26 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 24 Dec 2018 11:07:26 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> Message-ID: <1545667646.2463.103.camel@kitware.com> On Sat, 2018-12-22 at 16:57 +0100, Torsten Robitzki wrote: > What I?m still missing is support to define dependencies between > different targets (build by different toolchains), so that I can > describe that I require a tool that is build with the HostToolChain, > to generate a file that is required by the part of the build, that is > using the CrossToolChain. And, of cause, if the source of that tool > changes, that tool have to be rebuild and the generated file from the > CrossToolChain part of the build have to be rebuild. What about add_dependencies()? Is that sufficient, or is there something more that you need? Kyle From Torsten at Robitzki.de Mon Dec 24 16:24:45 2018 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Mon, 24 Dec 2018 22:24:45 +0100 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: <1545667646.2463.103.camel@kitware.com> References: <1545077919.2463.20.camel@kitware.com> <1545667646.2463.103.camel@kitware.com> Message-ID: <8AD2A19B-7D4D-48DC-A65A-AE25E0C905FA@Robitzki.de> > Am 24.12.2018 um 17:07 schrieb Kyle Edwards : > > On Sat, 2018-12-22 at 16:57 +0100, Torsten Robitzki wrote: >> What I?m still missing is support to define dependencies between >> different targets (build by different toolchains), so that I can >> describe that I require a tool that is build with the HostToolChain, >> to generate a file that is required by the part of the build, that is >> using the CrossToolChain. And, of cause, if the source of that tool >> changes, that tool have to be rebuild and the generated file from the >> CrossToolChain part of the build have to be rebuild. > > What about add_dependencies()? Is that sufficient, or is there > something more that you need? If it would be possible to use add_dependencies() to describe dependencies between two targets build with two different toolchains, then this would be sufficient: add_dependencies(signed_firmware TOOLCHAINS CrossToolChainA CrossToolChainB firmware_signing_tool TOOLCHAIN HostToolChain) best regards, Torsten From frodak17 at gmail.com Mon Dec 24 20:52:15 2018 From: frodak17 at gmail.com (frodak17) Date: Mon, 24 Dec 2018 20:52:15 -0500 Subject: [cmake-developers] Idea for Multi-Toolchain Support In-Reply-To: References: <1545077919.2463.20.camel@kitware.com> Message-ID: On Sat, Dec 22, 2018 at 10:58 AM Torsten Robitzki wrote: > Hi, > > > Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers < > cmake-developers at cmake.org>: > > > > Then, executables and libraries could have a toolchain specified: > > > > add_executable(BuildUtility TOOLCHAIN DEFAULT ...) > > add_library(MyLibrary TOOLCHAIN CrossToolchain ?) > > or even toolchains: > > add_library(feature1 TOOLCHAINS CrossToolChain HostToolChain) > > add_executable(Firmware TOOLCHAIN CrossToolChain) > target_link_libraries(Firmware feature1) > > add_executable(Test_Feature1 TOOLCHAIN HostToolChain) > target_link_libraries(Test_Feature1 feature1) > > A nice feature would be to let toolchain propagate along the dependency > graph defined by `target_link_libraries`. So in the example above, the > TOOLCHAINS option to `add_library` would be optional, because the target > Firmware requires feature1 to be build with CrossToolChain and > Test_Feature1 to be build with HostToolChain. Which requires the build to > have different binary directories for every toolchain. (Which for me is an > indication that having multidimensional build types would be the more > natural way to go) > > How would different binary directories for every toolchain work? CMAKE_CURRENT_BINARY_DIR wouldn't even be accurate let alone all of the code that tracks these things. Using target_compile_options() and file level compile options would have to use generator expressions to pass the correct flags to the correct toolchain. If TOOLCHAINS is specified and the CMakeLists.txt file only contains the library target then nothing is built because there is nothing linking against it? Offhand it seems to me that adding multiple binary directories based on which toolchain was used is a larger change to the infrastructure then adapting a generator to use multiple toolchains in its output. > What I?m still missing is support to define dependencies between different > targets (build by different toolchains), so that I can describe that I > require a tool that is build with the HostToolChain, to generate a file > that is required by the part of the build, that is using the > CrossToolChain. And, of cause, if the source of that tool changes, that > tool have to be rebuild and the generated file from the CrossToolChain part > of the build have to be rebuild. > > All the commands already support this. add_executable() rebuilds the host tool if the source file change for the tool is updated. add_custom_command() runs whenever any target specified in DEPENDS is rebuilt. So in this case you specify the custom command to run the host tool and generate the output and set DEPENDS to host tool target. If the host tool is updated due to a source file change then the tool is rebuilt and the file is regenerated. The cross toolchain target that uses the generated file rebuilds because the timestamp on generated file was updated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingjie.xing at gmail.com Tue Dec 25 01:17:25 2018 From: mingjie.xing at gmail.com (Mingjie Xing) Date: Tue, 25 Dec 2018 14:17:25 +0800 Subject: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY Message-ID: Hello, I run into a problem when use FindBISON module in CMakeLists.txt. The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR. The GNU Bison has problem for ??defines=? option because it will always generate the header file in the working directory. So, BISON_TARGET(Parser ${CMAKE_CURRENT_SOURCE_DIR}/Parser.y ${CMAKE_CURRENT_BINARY_DIR}/Parser.bison DEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/Parser.h) will not work, because ?Parser.h? will be generated under CMAKE_CURRENT_SOURCE_DIR. So I just wonder whither it is better for BISON_TARGET to use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY. Thanks Mingjie From mauro at faresoftware.it Sun Dec 30 12:51:22 2018 From: mauro at faresoftware.it (Mauro Ziliani) Date: Sun, 30 Dec 2018 18:51:22 +0100 Subject: [cmake-developers] Cmake and Embedded Visual C++ 4.0sp4 Message-ID: <72ec8090-1d63-1ba4-0d14-07cb61e335bd@faresoftware.it> Hi all. Anyone has work with cmake for EVC40? I'm using bakefile legacy but suddenly the vcp project file is not been loaded anymore :-( MZ From compnerd at compnerd.org Sun Dec 30 16:09:23 2018 From: compnerd at compnerd.org (Saleem Abdulrasool) Date: Sun, 30 Dec 2018 13:09:23 -0800 Subject: [cmake-developers] Referencing all sources in compile command Message-ID: Hi, I was looking at supporting Swift as a language in CMake. I know that CMake has some preliminary support that assumes that you are building on macOS with Xcode. I am trying to support building swift libraries and executables on Linux and Windows. There is some preliminary work on this that I have put up on GitHub [1]. One place that I am hitting a roadblock in is the need to reference all the target sources in the compile rule for a single object. AFAICT, there is no placeholder that will expand to the target sources. Would it be acceptable to add a `` place holder? Or is there another approach that would be better? Thanks. [1] https://github.com/compnerd/cmake-swift -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Mon Dec 31 10:14:18 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 31 Dec 2018 10:14:18 -0500 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: References: Message-ID: <1546269258.4676.8.camel@kitware.com> On Sun, 2018-12-30 at 13:09 -0800, Saleem Abdulrasool wrote: > Hi, > > I was looking at supporting Swift as a language in CMake.? I know > that CMake has some preliminary support that assumes that you are > building on macOS with Xcode.? I am trying to support building swift > libraries and executables on Linux and Windows. > > There is some preliminary work on this that I have put up on GitHub > [1].? One place that I am hitting a roadblock in is the need to > reference all the target sources in the compile rule for a single > object.? AFAICT, there is no placeholder that will expand to the > target sources.? Would it be acceptable to add a `` > place holder?? Or is there another approach that would be better? > > Thanks. > > [1]?https://github.com/compnerd/cmake-swift > > --? > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > --? > > 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/op > ensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers Saleem, Not sure if this will help, but have you taken a look at the $ generator expression? https://cmake.org/cmake/help/v3.13/manual/cmake-generator- expressions.7.html#output-expressions Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Dec 31 17:17:21 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 31 Dec 2018 17:17:21 -0500 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: References: Message-ID: <20181231221721.GA850@rotor.localdomain> On Sun, Dec 30, 2018 at 13:09:23 -0800, Saleem Abdulrasool wrote: > I was looking at supporting Swift as a language in CMake. I know that > CMake has some preliminary support that assumes that you are building on > macOS with Xcode. I am trying to support building swift libraries and > executables on Linux and Windows. IIRC, the issue before was that the command line interface to swiftc was basically treated as a black box and not stable (i.e., whatever Xcode wanted drove the interface, backwards compat was not guaranteed). Is that different now? > There is some preliminary work on this that I have put up on GitHub [1]. > One place that I am hitting a roadblock in is the need to reference all the > target sources in the compile rule for a single object. AFAICT, there is > no placeholder that will expand to the target sources. Would it be > acceptable to add a `` place holder? Or is there another > approach that would be better? The problem with that is that per-source file properties cannot be applied (compile definitions, flags, etc.). I don't know whether or not this is important for Swift. Other questions which spring to mind: - Does it support making just the compile artifacts from the source files or does it always do the link step? - If the latter, how do mixed language libraries work? - Also, if linking is done by Swift, how would one add a manifest or .rc file on Windows (e.g., to get an application icon)? The list of restrictions would need to be well-defined here first I think. --Ben From compnerd at compnerd.org Mon Dec 31 18:17:34 2018 From: compnerd at compnerd.org (Saleem Abdulrasool) Date: Mon, 31 Dec 2018 15:17:34 -0800 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: <1546269258.4676.8.camel@kitware.com> References: <1546269258.4676.8.camel@kitware.com> Message-ID: Hi Kyle, Thanks, I did look at generator expressions. However, they are expanded outside the scope of the placeholders and will be emitted into the generated build file, which makes them unusable in this scenario. On Mon, Dec 31, 2018 at 7:14 AM Kyle Edwards wrote: > On Sun, 2018-12-30 at 13:09 -0800, Saleem Abdulrasool wrote: > > Hi, > > I was looking at supporting Swift as a language in CMake. I know that > CMake has some preliminary support that assumes that you are building on > macOS with Xcode. I am trying to support building swift libraries and > executables on Linux and Windows. > > There is some preliminary work on this that I have put up on GitHub [1]. > One place that I am hitting a roadblock in is the need to reference all the > target sources in the compile rule for a single object. AFAICT, there is > no placeholder that will expand to the target sources. Would it be > acceptable to add a `` place holder? Or is there another > approach that would be better? > > Thanks. > > [1] https://github.com/compnerd/cmake-swift > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > -- > > 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 > > > Saleem, > > Not sure if this will help, but have you taken a look at the > $ generator expression? > > > https://cmake.org/cmake/help/v3.13/manual/cmake-generator-expressions.7.html#output-expressions > > Kyle > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: From compnerd at compnerd.org Mon Dec 31 18:30:28 2018 From: compnerd at compnerd.org (Saleem Abdulrasool) Date: Mon, 31 Dec 2018 15:30:28 -0800 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: <20181231221721.GA850@rotor.localdomain> References: <20181231221721.GA850@rotor.localdomain> Message-ID: Responses inline. On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel wrote: > On Sun, Dec 30, 2018 at 13:09:23 -0800, Saleem Abdulrasool wrote: > > I was looking at supporting Swift as a language in CMake. I know that > > CMake has some preliminary support that assumes that you are building on > > macOS with Xcode. I am trying to support building swift libraries and > > executables on Linux and Windows. > > IIRC, the issue before was that the command line interface to swiftc was > basically treated as a black box and not stable (i.e., whatever Xcode > wanted drove the interface, backwards compat was not guaranteed). Is > that different now? > AFAIK, the driver interface is supposed to be stable. The frontend options are not, but, the same holds true for clang as well. The driver options are stable, and we (as the clang developer community) aim to not break that. However, the frontend flags are entirely in the purview of the compiler developers and those change as needed. > There is some preliminary work on this that I have put up on GitHub [1]. > > One place that I am hitting a roadblock in is the need to reference all > the > > target sources in the compile rule for a single object. AFAICT, there is > > no placeholder that will expand to the target sources. Would it be > > acceptable to add a `` place holder? Or is there another > > approach that would be better? > > The problem with that is that per-source file properties cannot be > applied (compile definitions, flags, etc.). I don't know whether or not > this is important for Swift. > I think that there is some confusion over what exactly I need. I am trying to do file at a time compilation, but, each compilation requires the full set of sources to be provided to the driver. This effectively boils down to: swiftc -c -primary-file -o -emit-module-path .swiftmodule -emit-module-doc-path .swiftdoc This allows the compiler to look through the other sources which will be part of the module and perform semantic analysis across them if/when necessary. Adding per file properties would still be possible, and, IMO, desired. That is part of the reason for doing the compilation in this mode rather than a single pass over the complete file set. That said, most of the options really should be at a module level. > Other questions which spring to mind: > > - Does it support making just the compile artifacts from the source > files or does it always do the link step? > The approach that I am taking does a separate compile and link step. This allows for a better behavior when it comes to incremental builds which I care about. > - If the latter, how do mixed language libraries work? > The latter is what I believe most people have done, partially due to lack of understanding of how the build model works with swift which is completely understandable given that it is relatively opaque and it has not been documented as thoroughly as C/C++. - Also, if linking is done by Swift, how would one add a manifest or > .rc file on Windows (e.g., to get an application icon)? > Well, you would still want to link using the swift driver, not the linker directly much like you use the driver to link C/C++. I believe the changes have also been back ported to the 5.0 release to pass options from the [swift] driver to the [clang] driver to have them be translated appropriately for the linker in use. But, the manifest and resource file handling is done by the linker IIRC, so this is largely unchanged beyond the need to pass along the right flags. The list of restrictions would need to be well-defined here first I > think. > I think that there aren't very many restrictions that come to mind. The biggest one is that it would be *extremely* helpful to have language specific properties that can be set, but, I really was hoping that there was a way to do this with a backwards compatible manner. It would be helpful to have a property to indicate things like the swift version and the module name. I'm happy to go into more detail, but, I'm really not sure I have an understanding of what things you may be thinking of as restrictions here. > --Ben -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: