[cmake-developers] Idea for Multi-Toolchain Support

Kyle Edwards kyle.edwards at kitware.com
Wed Dec 19 14:25:58 EST 2018


On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote:
> I have thought about it which is why I asked.  The original
> assumption of one toolchain per CMake project is being extended. So
> why not think of extending the build type.  Sure it's simpler to
> ignore the build type. However, it doesn't make sense to me to build
> and run a host tool in debug mode when it could be running faster if
> built in release mode.  This is independent of whatever I'm doing
> with cross-compiler targets. You're already updating the generator to
> pick and choose the proper flags just on the tool chain type and it
> already picks the correct flags based on the configuration type.  But
> instead of the generator looking at the global build type it looks at
> the target build type. The target build type could default to the
> global build type and be overridden via a property.
> 
> Multi config generators would be problematic if they don't have a
> Configuration Manager that allows for setting different projects with
> different configurations (like Visual Studio) but is that reason
> enough to exclude the idea for single configuration generators?
I suppose we could consider the idea of supporting this separation for
single-config generators, but I can't think of a good way to make it
work for multi-config generators.
> If this can already be simply done why is anyone asking to use multiple toolchains in a single project?  You just use an ExternalProject with each toolchain file and you're done, or is this a shortcut method instead of using ExternalProject to build the host tool?
You can use ExternalProject, but it's a bit like using a chainsaw when
all you need is a scalpel. Multi-toolchain would make it easy to keep
host tools and target code in the same project in the *simple* case
(like the Linux kernel example I gave in a previous email.) If you want
to do something more complicated then ExternalProject would be your
best bet.
Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181219/8cbf27b3/attachment.html>


More information about the cmake-developers mailing list