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 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
-- 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
