Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
Andrey Pokrovskiy 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. There should be no need for that. With reference to what Brad wrote, you might find any of this interesting: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52129/focus=52142 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9578 Thanks, Steve. -- 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
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
On 04/26/2015 09:08 PM, David Cole via cmake-developers wrote: 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. On Sun, Apr 26, 2015 at 8:53 PM, Andrey Pokrovskiy 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. The intention of a file referenced by CMAKE_TOOLCHAIN_FILE is to contain information *local to the machine*, like the paths to installed SDKs for the target platform. It is *supposed* to be a local file not distributed with the project being built. Anything that would go in CMAKE_TOOLCHAIN_ARGS can just be put in that local file instead. Any information that is general knowledge about the target platform should be in the platform information modules that CMake loads based on the CMAKE_SYSTEM_NAME. The project may put these in CMAKE_MODULE_PATH. -Brad -- 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
[cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
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
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
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 dlrd...@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.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
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
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.m...@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 dlrd...@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.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: