<div dir="auto">> <span style="font-family:sans-serif;font-size:12.8px">which I bet all of us would love to see.</span><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional.</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer <<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 2018-11-09 10:04, schrieb Torsten Robitzki:<br>
> Hi,<br>
> I hope this question was not asked before. I work in the embedded<br>
> field and there it is usually to have at least two different build<br>
> platforms. The Host platform, where unit tests are build (and where<br>
> CMake is running) and an embedded Target platform, where targets are<br>
> build with a cross compiler. Sometimes such a system comes with<br>
> self-written tools that are build and run on the Host platform to<br>
> build a target for the embedded Target platform (adding meta data to a<br>
> binary to be used by a bootloader for example).<br>
> <br>
> Usually I have two different build folders, one for the Host platform<br>
> and one for the Target platform, using different calls to cmake to<br>
> choose from a set of tools and targets. But when using this approach,<br>
> it is necessary that the Host platform build ran before the Target<br>
> platform build, so that tools that are required for the Target<br>
> platform are build during the Host target build.<br>
> <br>
> One solution I’ve came up with, is to build the required tools during<br>
> the Target platform build, using an add_custom_target() to invoke the<br>
> Target compiler directly. This works fine, as long as the tools are<br>
> basically build just out of a couple of files.<br>
> <br>
> What would be the „CMake-Way“ to add the tools (that have to be build<br>
> on the Target platform) as dependency to targets that have to be build<br>
> for the Target (cross compile) platform?<br>
<br>
TL;DR: there is not "good" way yet. But there should be one.<br>
<br>
I'm hijacking this and move it to the developers list, because that is <br>
something "big", and we need to think about how to do that. I find it <br>
important to correctly solve this as it would simplify a lot of things. <br>
Especially given that Qt is thinking to use CMake to build Qt itself, <br>
which I bet all of us would love to see. But they will be after us if we <br>
don't offer a solution for this. And given the increasing amount of <br>
cross-setups these days I'm sure that a lot of other people would <br>
benefit.<br>
<br>
My first idea was to have something like add_host_executable(), which <br>
would only be called when this is not CMAKE_CROSSCOMPILING, but at the <br>
end I think this clutters things too much.<br>
<br>
Then I came up with:<br>
<br>
   add_host_build("relative source dir" "build dir" [VARS])<br>
<br>
This would create an entirely new CMake scope (with it's own <br>
CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", <br>
and would not take the CMAKE_TOOLCHAIN_FILE into account. People are <br>
free to pass "." as relative source dir in case they want to start at <br>
top level, but they may as well pass "tools", "generators" or whatever <br>
they call it. This is not intended to be called multiple times from the <br>
same project as it would scan for compiler and environment once for <br>
every call, but doing so does no harm beyond being slow(er) and the <br>
targets of one such sub-build not being visible to the others.<br>
<br>
My idea would be that things added by add_executable() inside such a <br>
sub-build are visible as targets from the outer build. Other things like <br>
libraries and the like need not to be, they can't be linked in the outer <br>
world. The user is free to build with shared libs inside, and running <br>
the things from the build tree would result in the correct freshly build <br>
libs being picked up because of RPATH or whatever. There is no install <br>
of those targets possible from the outer build, this can entirely be <br>
managed from the host build. Of course one must be possible to set <br>
variables on the host build, that's where VARS comes into play. This <br>
holds a list of variable names that will be passed to the hostbuild. No <br>
values, to avoid all sorts of quoting issues. Helpful would be a special <br>
variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and <br>
a non-sysroot thing prefix in the toolchain file). Confused? Granted, <br>
here is an example:<br>
<br>
if (CMAKE_CROSSCOMPILING)<br>
     set(HOST_INSTALL_DIR "/some/where")<br>
     add_host_build(. host HOST_INSTALL_DIR)<br>
endif ()<br>
add_executable(magic magic.cpp)<br>
install(TARGETS magic DESTINATION bin) # installs both the host and the <br>
target tool!<br>
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND <br>
magic) # will call the host build<br>
if (NOT CMAKE_HOST_BUILD)<br>
     add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)<br>
     install(TARGETS foo DESTINATION bin)<br>
endif ()<br>
<br>
This should end up in a layout like this:<br>
<br>
/tmp/install/prefix/tools/bin/magic.exe # Windows host<br>
/tmp/install/prefix/sysroot/usr/bin/magic # Unix guest<br>
/tmp/install/prefix/sysroot/usr/bin/foo<br>
<br>
The toolchain file would look somehow like this:<br>
<br>
set(CMAKE_HOST_PREFIX prefix<br>
set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot)<br>
<br>
and the CMake command would look like this:<br>
<br>
cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D <br>
CMAKE_HOST_INSTALL_PREFIX=tools ...<br>
<br>
The wish-season is coming up, so that's sort of what I would like to <br>
have. Now it's your turn. No bikeshedding please, only deliveries ;)<br>
<br>
Eike<br>
-- <br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div>