[cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

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: <https://cmake.org/pipermail/cmake-developers/attachments/20181217/f3595625/attachment.html>