provide NDK integration for CMake as part of the NDK package

[DanAlbert]

@bradking @rcdailey @kravindran

Tracking bug for getting the NDK's CMake support integrated with the stuff built in to CMake.

Based on a chat we had with @bradking, the right approach here is to teach CMake to load most of the knowledge that is currently in our cmake toolchain from the CMake side of things. If CMake is building for the NDK and it finds those files in the NDK (it won't for NDK releases prior to this being fixed), it will import those NDK modules to allow us to override CMake's rules (so we can add features that don't require a new CMake release).

We'll still need a CMake toolchain file in the NDK that uses these plugins for the foreseeable future since we still need to support versions of CMake older than whatever version this new implementation makes it into.

https://android-review.googlesource.com/c/395513/ was the first stab at implementing this. It's definitely bitrotted by now, and it still needs the CMake side of the work to be done (not sure if @kravindran had some WIP commits for this, but I didn't find them).

EDIT 22 Jan 2019

The most up to date plan for this is to ship the Platform/*.cmake files that CMake uses to support Android as part of the NDK itself. The toolchain file will continue to exist as a way to interface to this new implementation. When using an older version of CMake, the toolchain file will need to disable policy CMP0017 (hopefully that's the only workaround that we'll need).

This gives the NDK the control it needs to work around toolchain bugs and update default behaviors while also reducing the friction caused by the toolchain file that does much more than toolchain files were ever intended to do.

[Zingam]

Now that AS 3 supports external CMake and hopefully will work in Beta 8 will you prioritize completing the CMake integration?

[DanAlbert]

@kravindran, any update on this?

[alexcohn]

What about 'teaching' cmake to use Android.mk? I mean, let it invoke ndk-build for sub-modules.

[DanAlbert]

Unfortunately the Studio engineer that was working on this left the team quite some time ago (hence the lack of updates). I'll most likely be picking this up in r20.

This is something that should get a lot simpler with r19 since most of the knowledge that CMake currently needs is just going to be set as toolchain defaults. I'm guessing I won't have time to fix both the NDK and CMake in r19 though, which is why this is being slated for r20 instead. If I'm wrong and have time in r19, I'll pull this work in to that release.

[Zingam]

This issue should be a priority really. I hope that it won't get postponed too much again for some reason.

[DanAlbert]

While I don't disagree, I do wonder: why do folks think this is a priority? It's a priority for me because it causes a ton of confusion, especially for beginners (I 100% agree that it's absurd that this is a situation that even needs to be explained). Is that your reason? I would imagine that it doesn't matter much after the initial confusion is cleared up since I don't suspect people care how it's implemented, just that they have something that works, which is the case today.

Regardless, yes, this is approaching the near term road map. The r19 toolchain updates (i.e. not needed to pass a hundred flags to make clang work) are a part of this, it's just not the complete project.

[alexcohn]

To begin with, there should be easily discoverable instructions on how to build something for Android with CMake from command line (i.e. not through Android Studio).

[rcdailey]

I worked a lot with Dan and the CMake guys on this a few months ago, which is why this issue exists. I struggled getting CMake's built-in Android support to work with the NDK because CMake missed a lot of edge-case type stuff that the toolchain was doing. So there were a lot of cases where builds would fail and I just couldn't get it working.

From the developer team perspective, when the NDK changes, CMake also has to change (if not using the toolchain). Right now the NDK developers update just 1 project, but now they somehow need to update an unrelated one any time they make a change to the NDK. I'm also not sure what the backward compatibility implications are (looks like it can be handled in Modules/Platform/Android-Determine.cmake. I don't have much insight here but it seems like more management overhead for the NDK project, and there wasn't an immediate need for it. I'm not sure how things will work going forward with that additional dependency on CMake.

From my perspective, the toolchain isn't much harder to use than the built-in version. The parameters are mostly the same. Furthermore, you likely have build scripts to help generate projects using CMake for the NDK platform, which can simplify/hide the details of how you invoke CMake to build for those platforms. There is no sense of urgency from my perspective. I'm able to use the newest version of CMake today with the NDK's provided toolchain just fine.

In terms of "easily discoverable instructions", it already is. You only have two places to look:

• For toolchain usage, read the comment section at the top of the toolchain.cmake file
• For built-in platform support of NDK in CMake, there's a documentation page.

So: Documentation is fine, there's no urgency. To be honest, the only reason I think this issue even exists is at the request of the CMake developers. They've asserted (and I agree) that toolchain files are not supported to (and were not designed to) do a lot of system introspection. They're meant to describe some requirements for the platform but that's it. It's supposed to be a simple 20 line file (tops). But the NDK toolchain obviously violates those philosophies, so the developers there are agreeing to follow the CMake principles and treat their NDK as a platform in CMake, the same way it treats linux, windows, etc.

Maybe I'm missing some important aspects of this, but as far as my involvement goes and as a user of both CMake and Android NDK, that's my understanding.