[cmake-developers] Using multiple toolchains

[Eric Noulard]

2013/7/4 Stephen Kelly <steveire at gmail.com>:
[...]
>
> My approach comprises several steps:
>
> 1. Refactor cmake so that more that one toolchain can be available at
>    a time.
> 2. Make host+target builds possible in a single buildsystem by initializing
>    both the host and the target toolchain, specifying whether to find
>    dependencies in the host or the target, and specifying whether to build a
>    particular cmake-target for the host or for the target system. This does
>    not expose us to problems of clashes of cmake-target names for multiple
>    toolchains or problems of defining multiple per-toolchain make-targets
>    for a single cmake-target as all of those things remain impossible at
>    this step. This step requires some way to define such distinctions in
>    front-end CMakeLists.txt files. Possibly something like a toolchains()
>    command scoped to end with a endtoolchains() command.
> 3. Make it possible to define multiple toolchains to build a single target
>    for. Still only two toolchains are possible (host+target), but now we can
>    define that a single cmake-target created with add_executable should be
>    built for both the host and the target. Consider moc for example, which
>    might make sense to build for both so that target-on-target builds (or
>    target-in-target-vm builds) can be done. In addition to step two, this
>    step requires solving the disabmiguation problems of cmake-targets and
>    other problems that come from using multiple toolchains from one
>    cmake-target definition.
> 4. Make it possible to use N target toolchains. This takes advantage of the
>    solutions created in step 3. In addition to step 3, this step requires
>    deprecation of the undocumented CMAKE_TOOLCHAIN_FILE in favor of
>    something which can be a list, and it requires some way of attaching
>    names to toolchains. Projects using this have the disadvantage that there
>    is nothing but convention to standardise toolchain names. One project
>    might use RaspPi as a toolchain name in a CMakeLists.txt file, while
>    another uses RaspberryPi and yet another Raspbian. Qt has a similar issue
>    with device mkspec names.
>
>> While the work in your branch has gotten
>> impressively far, it also serves to demonstrate the inherent
>> complexity of the proposed approach.  IMO it is not worth exploring
>> that approach further.  Sorry.
>
> That reaction is not what I was hoping for. :)

I was surprised by Brad's answer as well.

> My branch makes a start mostly on steps 1 and 2 above, and to a small
> extent, step 4. 80% of the motivation and value of multiple toolchains comes
> from step 2, so I would happily truncate the other two as goals or leave
> them to future exporation.

+1
I do agree with that, I'm seldomly do cross-compiling but when I do
miss the native+target compilation I was used to when I was using
hand-written recursive makefile system 10+ year agos.

> I don't think an inappropriate amount of work or fundamental change to cmake
> is required to achieve step 2.

"innappropriate amount" heavily depends on who is doing the job but I guess
that the already proven workload given by Stephen to CMake speaks for itself.
I'm pretty sure he'll manage to do that.

The main issue would be, could it become a nightmare to maintain?

I did not manage to have so much time on the CMake front lately but
I'll try to follow and test Stephen work on that if it is going on.


--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org