On 06/27/2017 11:36 AM, Robert Dailey wrote: > Ok maybe I'm misunderstanding the design intent for toolchain files.
Originally they were intended to contain information local to the machine, like `set(CMAKE_ANDROID_NDK /path/on/my/machine/to/ndk)`. In controlled environments that share many things it makes sense to have deployable toolchain files instead. > 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 Toolchain files can `include()` other files from next to them. That can be used to avoid duplicate code. The only information you need within your toolchain file logic to compute CMAKE_ANDROID_NDK_DEPRECATED_HEADERS is CMAKE_ANDROID_NDK. If you add logic to find/require CMAKE_ANDROID_NDK up front then you can check its version. CMake's `Modules/Platform/Android-Determine.cmake` file has very little logic to choose `CMAKE_ANDROID_NDK` if it is not set by the user. You can either duplicate this in a toolchain file helper or take advantage of knowledge about your controlled environments to have a shorter version. -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
