[cmake-developers] Idea for Multi-Toolchain Support

[frodak17]

> How does this work with multiple languages and the project() command and
>> enable_language() commands?
>>
> Both project() and enable_language() could be extended with an optional
> TOOLCHAIN argument.
>

So it would be something like project(<PROJECT-NAME> [TOOLCHAIN
<toolchain-name> [LANGUAGES] [<language-name>...]) where TOOLCHAIN and its
supported languages can be repeated for each tool chain. i.e
project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross LANGUAGES
c)

For instance you want to use the host c++ compiler and a toolchain
> specified compiler for c and c++.
> When project() enables the c++ compiler it runs through a bunch of scripts
> to find and test the compiler also setting several CMAKE_<lang>_* variables
> to use that compiler.  These variables also happen to be the default
> compile options for the build types when using that compiler.
>
>
> The point of this idea is to get rid of the old variable-based system and
> have everything instead be a property of a toolchain. So the scripts would
> set properties of the default toolchain instead of setting variables.
>
> Then the same thing happens with the tool-chain specified compiler for
> these languages how do you track that the variables are different for these
> two toolchains?
> Are these variables now project scoped and for any given project it is
> limited to one toolchain per language per project?
>
>
> See above.
>

But isn't this all (or mostly) cached so you don't have to redo all this
when regenerating build files. I guess it would be
CMAKE_<toolchain>_<lang>_* ?

What about conflicting build types when building a host tool target vs the
cross compiler target?
For instance the host tool may (should?) be built as a release project
(default optimization levels) but the cross compiler project could be built
as a debug project (so you can debug it with no optimizations)?
I guess it would then be CMAKE_<toolchain>_BUILD_TYPE and then targets
using that toolchain would be built with that build type.

On the other hand this doesn't really help anyone working with mixed build
systems.  What you can't do in a straight forward manner is host tool
development with Visual Studio or Eclipse, execute it and use it's results
with a cross compiler (that uses Ninja or Makefiles) targeting an embedded
system.

In this case I think that what you want is to easily control multiple
projects using different build systems, the inter-dependencies, and easily
specify that external project A produces a file for external project B.
Ideally you would be in the root of the build folder and type 'cmake
--build .' and have it take care of everything with minimal extraneous
build tool executions or sometimes even invoking the build tool in parallel
for external projects that don't depend on each other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181218/19f2dfed/attachment.html>