[cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

David Cole DLRdave at aol.com
Sun Apr 26 21:08:21 EDT 2015


I realize that sometimes dependencies are necessary.

But.

There's a very strong argument to be made that projects should not
have "a lot" of external dependencies.

If you really need to tell an ExternalProject "build this external
project the same way as the main one," you should probably write code
(perhaps a wrapper of ExternalProject itself) that literally passes
the entire CMakeCache.txt of the main project down to the external
project.

I really don't see how you solve the problem by having a toolchain
file and some arbitrary set of variables to be passed down. Either you
have to put the CMAKE_TOOLCHAIN_ARGS into the toolchain file itself,
or you have to specify the complete set of what defines
CMAKE_TOOLCHAIN_ARGS. If you have a set, how do you add to it? Why not
just have them in the file? If the set changes from project to project
or toolchain to toolchain, then how can you define it so that it's
generally useful?


D




On Sun, Apr 26, 2015 at 8:53 PM, Andrey Pokrovskiy
<wonder.mice at gmail.com> wrote:
> Because it will be an ad-hoc solution. Also each time I will start
> using a new toolchain file (for another device/platform) I will need
> to modify that wrapper script. And each time I will override some
> toolchain variable I will need to look into that wrapper to verify
> that this variable will be forwarded. Wouldn't it be nice if there was
> a simple way to tell "build this external project the same way as a
> main one"?
>
> I'm not saying that the problem is unsolvable. I'm saying that right
> now CMake is not very convenient for projects with a lot of external
> dependencies. And specifying toolchain and it's options is a one
> aspect of it (not the most important, though).
>
>
> On Sun, Apr 26, 2015 at 5:36 PM, David Cole <DLRdave at aol.com> wrote:
>> Why wouldn't you just write your own "toolchain wrapper" file which
>> has all the variables you speak of, but also includes the "real"
>> toolchain file, and then use the wrapper as your CMAKE_TOOLCHAIN_FILE
>> value ... ?
>>
>>
>> D
>>
>>
>>
>> On Sun, Apr 26, 2015 at 7:32 PM, Andrey Pokrovskiy
>> <wonder.mice at gmail.com> wrote:
>>> Hi,
>>>
>>> I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
>>> dependencies. Some toolchain files have additional options (like API
>>> version, target architecture, linker type, etc.) which you need to
>>> pass to cmake command with "-D" in addition to the
>>> "-DCMAKE_TOOLCHAIN_FILE=" itself.
>>>
>>> So when you want to build some dependency with ExternalProject_Add()
>>> it's not enough to pass the same CMAKE_TOOLCHAIN_FILE. You also need
>>> to explicitly specify all other toolchain variables that you care
>>> about. That means that each time you start to override another
>>> toolchain variables or add a new toolchain, you need to carefully add
>>> proper variable forwardings to each ExternalProject_Add() call. This
>>> is not convenient and error prone.
>>>
>>> What do you think about formalizing toolchains a bit further? For
>>> example, it would be nice to have a way to get all variables (with
>>> their values) that are relevant for the current toolchain. Consider:
>>>
>>>     ExternalProject_Add(websockets_ep
>>>         CMAKE_ARGS
>>>             -DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE}
>>>             -DCMAKE_TOOLCHAIN_ARGS:string=${CMAKE_TOOLCHAIN_ARGS})
>>>
>>> Where ${CMAKE_TOOLCHAIN_ARGS} expands to "VAR1=VAL1;VAR2=VAL2;" (I
>>> realize that will not work like that, but conceptually) which defines
>>> toolchain configuration.
>>>
>>> For example, well behaved toolchain file could be asked to mark each
>>> configuration variable:
>>>
>>>     toolchain_option(ANDROID_NATIVE_API_LEVEL)
>>>
>>> so CMake after processing of a toolchain file can have a list of all
>>> relevant variables. Or maybe CMake can track all variables "touched"
>>> by the toolchain file.
>>>
>>> What do you think about that?
>>> --
>>>
>>> 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:
>>> http://public.kitware.com/mailman/listinfo/cmake-developers


More information about the cmake-developers mailing list