Re: [cmake-developers] Idea for Multi-Toolchain Support
Eric,
Thanks for the feedback. See comments below.
On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:
> > 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.h
> > tml
If you're talking about the issue of specifying multiple toolchain
files on the command line, I'm imagining a design like this:
add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET})
and then specify it on the command line with:
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake
-DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake
> > 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.
If you want to build the same target with multiple toolchains then I
think you're better off declaring them as different targets, with
different TOOLCHAINs but the same source files, etc.
> > ... 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.
>
My vision for this feature is that the project specifies the names of
the toolchains that it's expecting, and the toolchain file is agnostic
of this - it simply sets the properties of the toolchain named
${CMAKE_SELECTED_TOOLCHAIN}.
If you want to have a variable number of toolchains, you could do
something like this:
set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of
toolchains")
foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES})
add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}})
add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for
each target platform
endforeach()
Kyle--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
Le lun. 17 déc. 2018 à 22:04, Eric Noulard 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@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
>
... 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.
--
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
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@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 conv
[cmake-developers] Idea for Multi-Toolchain Support
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)
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.
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.
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.
Kyle
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
