<div dir="ltr">Hey all, just thought I would chime in and note that I very often write code that I expect to run both on my robots hardware and on my development machine in a simulator. In this case, I want the same target names and everything -- I simply use two cmake build directories, and now there is even support for this workflow in CLion so my life is very easy. Doing all of those as two targets with distinct names would be cumbersome, and the current system works very well for me.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 8:54 PM frodak17 <<a href="mailto:frodak17@gmail.com">frodak17@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards <<a href="mailto:kyle.edwards@kitware.com" target="_blank">kyle.edwards@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>I think that both host and cross targets would be built with the same build type. If you're using a multi-config generator like VS or Xcode, how do you specify which combination of configs you want? It's simpler if every target is built as the same type, whether it's host or cross. Think about it - the current system already expects that every target in the project is built as the same build type. There's no way to specify "foo is built as debug, bar is built as release." Why would this assumption change just because we add a multi-toolchain mechanic?</div></div></blockquote><div><br></div><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>Every target would be built by the same generator regardless of whether it's a host or cross target. So if you select the VS generator, both the host tools and the embedded software would be built in VS (if this is possible.) Likewise for Ninja and Make.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div class="gmail_quote"><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.</div></div></div></div>
</blockquote><div><br></div><div>If you want to build different parts of the software with different generators (build systems) then you're better off using a superbuild with ExternalProject. The intent of this proposal is to allow users to build both host tools and cross-compiled software in the same build tree with the same generator.</div></div></blockquote><div><br></div><div>Sure.  I was thinking / commenting about the other real world projects that are more complicated.  Can add_custom_command() be used to run a binary that was built as an ExternalProject which it was linked via depends to generate a file that is used by several other ExternalProjects and it's all glued together with proper dependencies so it can be invoked by a single command?<br></div><div><br></div>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 class="gmail_quote"><br></div><div class="gmail_quote">If ExternalProject doesn't define a target that can be used as a dependency for add_custom_command() or add_dependencies() then isn't this a problem which is driving people to ask to use multiple toolchains?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://cmake.org/pipermail/cmake-developers/2018-December/030920.html" target="_blank">https://cmake.org/pipermail/cmake-developers/2018-December/030920.html</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">This email seems to indicate that ExternalProject can't be used with add_custom_command().<br></div></div></div>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake-developers</a><br>
</blockquote></div>