[cmake-developers] Idea for Multi-Toolchain Support

Peter Mitrano mitranopeter at gmail.com
Wed Dec 19 00:05:06 EST 2018


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.

On Tue, Dec 18, 2018 at 8:54 PM frodak17 <frodak17 at gmail.com> wrote:

>
>
> On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards <kyle.edwards at kitware.com>
> wrote:
>
>> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
>>
>> 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.
>>
>>
>> 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?
>>
>
> 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?
>
>> 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.
>>
>>
>> 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.
>>
>> 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.
>>
>>
>> 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.
>>
>
> 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?
>
> 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?
>
> 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?
>
> https://cmake.org/pipermail/cmake-developers/2018-December/030920.html
>
> This email seems to indicate that ExternalProject can't be used with
> add_custom_command().
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181219/a242378c/attachment-0001.html>


More information about the cmake-developers mailing list