NDK 26 support

[keith]

Based on this https://github.com/android/ndk/wiki#release-schedule NDK 26 should be released sometime in Q3. I did some light testing and it seems like some files moved around that leads to everything failing today. I'm not sure if those types of moves are tracked anywhere? But I wanted to file this as a tracking issue for supporting the new version.

One open question I have is, should we be trying to maintain backwards compatibility in this case like bazel did before, or not?

[keith]

cc @cpsauer have you looked at this at all?

[keith]

After some testing it seems like #41 is roughly what would be required for the simplest case

[keith]

I don't see anything about this in the changelog so far https://github.com/android/ndk/wiki/Changelog-r26, but maybe that kind of re-arranging isn't documented either

[cpsauer]

Haven't yet, Keith, but really appreciate your moving this along.
Closest was trying to merge in support for major improvements in the backwards compatibility story (like Apple's @availables) in #27

[I rather suspect Google probably has all this in their internal version, so maybe we can get a Googler to help export or otherwise facilitate collaboration? Really wish there were a good way to collaborate rather than this being a fork.]

[keith]

I updated my PR to be backwards compatible, but would definitely love to hear from @ahumesky if this is the right path #41

[DanAlbert]

We don't document when clang internals move around, no (we aren't usually aware that it's happened). The libandroid_support removal is a part of the kitkat removal. It was never needed for minSdkVersion >= 21. The changelog really only documents user facing changes, not build system maintainer things. https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md is the source for that (and it was missing the lib directory rename, so https://android-review.googlesource.com/c/platform/ndk/+/2670239 fixes that).

(I agree we probably should maintain a separate "changes" list in that build system maintainers doc, but it's next to impossible for me to go write that after the fact)

[keith]

Thanks for the context! So seems like my changes are alright, but maybe we should improve this further by calling -print-resource-dir which I think would be fine for us to do

[DanAlbert]

That's how ndk-build deals with it. If it's an option for you it's going to be the most future proof path.

[keith]

#42

[ahumesky]

#42 is merged