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.m...@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
-- 

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

Reply via email to