2013/7/4 Stephen Kelly <[email protected]>: [...] > > 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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
