<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Kyle,</div><div><br></div><div>Is your proposal a follow-up on the initial bunch of ideas launched in this thread launch by Eike in November </div><div><a href="https://cmake.org/pipermail/cmake-developers/2018-November/030913.html">https://cmake.org/pipermail/cmake-developers/2018-November/030913.html</a><br></div><div>with follow-up ideas in in december:</div><div dir="ltr"><a href="https://cmake.org/pipermail/cmake-developers/2018-December/030920.html">https://cmake.org/pipermail/cmake-developers/2018-December/030920.html</a><br></div><div dir="ltr"><br></div><div>or is it somehow unrelated?</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <<a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
One of the things that's long been requested of CMake is the ability to<br>
have multiple toolchains - for instance, one host toolchain and one<br>
cross toolchain, so that "utilities" needed for build can be built with<br>
the host toolchain and then the "real" software can be built with the<br>
cross toolchain.<br>
<br>
To solve this problem, I would like to propose the creation of a new<br>
first-class object type, the "toolchain" type, which would replace the<br>
current variable-based system, similar to how imported targets replaced<br>
variable-based usage requirements.<br>
<br>
Every project would automatically receive one toolchain, the "DEFAULT"<br>
toolchain, which would be either automatically configured or configured<br>
based on CMAKE_TOOLCHAIN_FILE, just like the current system. New<br>
toolchains could be added with the add_toolchain() command:<br>
<br>
add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)<br></blockquote><div><br></div><div><div>This has some common design issue as my proposal:</div><div>enable_cross_target(...)<br></div><div>for which Eike has valuable doubt:</div><div><a href="https://cmake.org/pipermail/cmake-developers/2018-November/030919.html">https://cmake.org/pipermail/cmake-developers/2018-November/030919.html</a> </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Then, executables and libraries could have a toolchain specified:<br>
<br>
add_executable(BuildUtility TOOLCHAIN DEFAULT ...)<br>
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)<br>
<br>
Note that the TOOLCHAIN argument is optional, and if omitted, the<br>
DEFAULT toolchain is used.<br></blockquote><div><br></div><div>So if you want to build both for host and cross toolchain you'll have to explicitely </div><div>add_executable/library(MyLibrary TOOLCHAIN DEFAULT)</div><div><div>add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)</div><div><br></div><div>If you follow the previously referred discussion you cannot assume that one lib/exe</div><div>built for a toolchain is not built for another toolchain as well.</div></div><div><br></div><div>How do you envision the cross-toolchain target dependency which was</div><div>a question raised several time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
If a project uses multiple toolchains, we could have the option to<br>
rename the default toolchain with an alternative add_toolchain()<br>
syntax:<br>
<br>
add_toolchain(HostToolchain DEFAULT)<br>
<br>
Rather than adding a new toolchain, this would simply rename the<br>
"DEFAULT" toolchain to "HostToolchain". Then the toolchain<br>
specification for each target could look like this:<br>
<br>
add_executable(BuildUtility TOOLCHAIN HostToolchain ...)<br>
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)<br>
<br>
Two new global read-only properties would be added: TOOLCHAINS and<br>
DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of<br>
all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of<br>
the DEFAULT toolchain (which could be changed with the alternative<br>
add_toolchain() syntax.)<br>
<br>
The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than<br>
setting variables:<br>
<br>
set(CMAKE_C_COMPILER /usr/bin/gcc)<br>
set(CMAKE_C_COMPILER_ID gnu)<br>
# etc.<br>
<br>
it would instead set properties on the selected toolchain:<br>
<br>
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER<br>
/usr/bin/gcc)<br>
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY<br>
C_COMPILER_ID gnu)<br>
# etc.<br></blockquote><div><br></div><div>I don't see why we should change the syntax of current toolchain file, I don't see the benefit.</div><div>CMake already knows when (and which) toolchain file is loaded and it could perfectly automatically </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain<br>
file either at the root or by the add_toolchain() command.<br>
<br>
If you want to read the value of C_COMPILER, etc. then just use<br>
get_property():<br>
<br>
get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)<br>
<br>
Obviously this system would scale well to more than just two toolchains<br>
- just use as many add_toolchain() commands as you need.<br>
<br>
Backwards compatibility is going to be a challenge. Both the toolchain<br>
file and the project have to be aware of the new toolchain system,<br>
which means we have to handle four permutations:<br>
<br>
1) old toolchain + old project<br>
2) old toolchain + new project<br>
3) new toolchain + old project<br>
4) new toolchain + new project<br>
<br>
I propose adding a policy that both the toolchain file and the project<br>
can set separately, and which would have a slightly different meaning<br>
in each one. If the toolchain is OLD and the project is NEW, then the<br>
variables set by the toolchain file would be converted into properties<br>
on the toolchain for the project. If the toolchain is NEW and the<br>
project is OLD, then the properties on the toolchain would be converted<br>
into variables in the project. If both the toolchain and project have<br>
the same value, then no special conversion is required.<br>
<br>
I would welcome everyone's feedback on this proposal. Obviously this is<br>
a big change to how CMake handles toolchains, and would require a lot<br>
of very deep refactoring.</blockquote><div><br></div><div><br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div></div></div>