<html><head></head><body><div>On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote:</div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>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.<br></div><div><br></div><div>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?<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote">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?</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Kyle</div></body></html>