<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 17 déc. 2018 à 22:04, Eric Noulard <<a href="mailto:eric.noulard@gmail.com">eric.noulard@gmail.com</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"><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div></div></blockquote><div><br></div><div>... sorry wrong key pressed...</div><div><br></div><div>CMake could perfectly automatically create the new "TOOLCHAIN" object by loading the very</div><div>same toolchain file as we have today. We could simple add a new variable</div><div>CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name them as he wants.</div><div>When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div>