<div dir="ltr"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How does this work with multiple languages and the project() command and enable_language() commands?<br></blockquote><div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Both project() and enable_language() could be extended with an optional TOOLCHAIN argument.</div></blockquote><div><br></div><div>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)<br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>For instance you want to use the host c++ compiler and a toolchain specified compiler for c and c++.</div><div>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.<br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>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?</div><div>Are these variables now project scoped and for any given project it is limited to one toolchain per language per project?</div></div></div>
</blockquote><div><br></div><div>See above.</div><div></div></div></blockquote><div><br></div><div>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>_* ?</div><div><br></div><div>What about conflicting build types when building a host tool target vs the cross compiler target?</div><div>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)?</div><div>I guess it would then be CMAKE_<toolchain>_BUILD_TYPE and then targets using that toolchain would be built with that build type.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><br><div><br></div><div><br></div></div></div>