[cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

Just wanted to share my solution to this, based on your suggestions
about code sharing. I still do some introspection but some of this is
based on our usage of environment variables and such. However the
logic to find NDK version is useful in general.

Instead of pasting the CMake code here, I have made it available as a gist:
https://gist.github.com/rcdailey/ae336b48b8681897c747524a5713c6c6

Hope this helps others that have similar questions. Thanks again Brad.

On Tue, Jun 27, 2017 at 11:07 AM, Brad King <brad.king at kitware.com> wrote:
> 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
>