[cmake-developers] Idea for Multi-Toolchain Support

Eric Noulard eric.noulard at gmail.com
Mon Dec 17 16:06:33 EST 2018

Le lun. 17 déc. 2018 à 22:04, Eric Noulard <eric.noulard at gmail.com> 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)
>> # etc.
>> it would instead set properties on the selected toolchain:
>> /usr/bin/gcc)
>> # 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181217/ddc1b2fa/attachment-0001.html>

More information about the cmake-developers mailing list