On Tue, Jun 27, 2017 at 10:22 AM, Brad King <brad.k...@kitware.com> wrote: > On 06/27/2017 11:14 AM, Robert Dailey wrote: >> Also at $DAYJOB, we all work on the same code base. Our product is >> tested and verified to work on a distinct set of configurations. Why >> would I ask each user to create their own toolchain file? > > If you have a toolchain file that works in some finite set of > tested environments then there is no reason not to share it > among them. > > Why can't the logic to choose `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS` > be in your toolchain file? All it needs to know is the NDK location.
Ok maybe I'm misunderstanding the design intent for toolchain files. I agree they shouldn't do much introspection (i.e. "business logic"), but I've always made sure to provide multiple toolchain files if necessary in version control, one per supported (tested) configuration for the code base. Generally speaking, I provide one per supported platform (Android, Windows, Linux, etc). However, I will not specify things in the toolchain file that are not "static". Basically, some things I like to determine programmatically. Putting in them in the toolchain file violates the "introspection" rule, but also results in code duplication since I have to do that same introspection in each toolchain file. So my specific case is this: Unified headers have been supported since NDK r14. However, because of certain libraries and language features that we use, our code fails to compile due to bugs in the unified headers. Again for our specific code base, these bugs are addressed in NDK r15b. So now I'm faced with a situation: Just because unified headers are present doesn't mean we should use them. So I can no longer base the decision to use unified headers on when they were introduced, but it needs to be based on an arbitrary NDK version. To solve this issue, I have come up with this logic: https://gist.github.com/rcdailey/0ee52bfca634e7da55b6f86b9af91911 This CMake logic allows me to obtain the version of the NDK the user has on their system and based on that version I can strategically set the CMAKE_ANDROID_NDK_DEPRECATED_HEADERS variable. This is all transparent to users on my team. None of them have done the research I have into this, so they would not know which NDK to use or when to set this flag to 1 or 0. We support r14 and r15 in different environments. Maybe my situation is the exception to the rule, but I just don't see an elegant way to do what I want. -- 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
