Basic CMake setup with NDK and MediaNDK

[DenverCoder21]

Hello folks, I'm new to the Android NDK, MediaNDK and so on.

At the moment, I am trying to set up a simple, hello-world-like project to learn and understand what the canonical way of integrating the NDK looks like.

I am struggling with quite a few things, so let me show some code first.

CMakeLists.txt

src/main.cpp

Which yields the following message when building.

This does not surprise me too much, because I have added no include directories whatsoever. So how do I do that correctly? I've found it's possible to use one of the provided toolchain files, which I hoped would take care of that for me but somehow didn't work.

Also I just noticed, that NdkMediaCodec.h is located in a bit of an unexpected location at:

/opt/homebrew/Caskroom/android-ndk/24/AndroidNDK8215888.app/Contents/NDK/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/media/NdkMediaCodec.h

I have also found guides that recommended calling find_library(mediandk-lib mediandk), but one comment from, iirc, Dan in some of the GitHub issues says that was never really necessary.

I've been mostly following these guides:

Android NDK & CMake

CMake Toolchains

Also, to be clear: This is not supposed to live inside of an Android Studio project; The way our C++ library is set up at the moment is a C++ repository in itself. We build and then publish to a Maven repository from which our Android app consumes the library. We have been using polly and Hunter package manager so far. The latter has been replaced by Conan, but polly sticks around and I would like to get rid of that bloat.

So to sum up, these are questions that still puzzle me:

• Is my general approach correct? Which parts are wrong?
• Do I need to explicitly set a toolchain file as in a certain android.toolchain.cmake, or is a folder enough or should it also work without providing a CMAKE_ANDROID_STANDALONE_TOOLCHAIN or CMAKE_TOOLCHAIN_FILE?
• Would using the CMake Standalone Toolchain [1] file way be more convenient and preferable over the 'regular' Cross-Compiling for Android with the NDK [2]?
• How should setting the include directories be handled?
• Should I use a find_library() call?

Any advice is appreciated, maybe he have a fundamentally wrong concept of how this is supposed to be done. Thank you!

[1] https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-android-with-a-standalone-toolchain

[2] https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-android-with-the-ndk

[Dan Albert]

I've answered this on your SO post mirroring it: https://stackoverflow.com/a/72987366/632035. I'll answer the direct questions here as well:

• Is my general approach correct? Which parts are wrong?

I'd definitely recommend using our CMake toolchain file. The built-in workflow offers no improvements that I'm aware of, and certainly does seem to work less well. We've put in a fair amount of time trying to make it work well, but after years it's still not at parity with our toolchain file.

• Do I need to explicitly set a toolchain file as in a certain android.toolchain.cmake, or is a folder enough or should it also work without providing a CMAKE_ANDROID_STANDALONE_TOOLCHAIN or CMAKE_TOOLCHAIN_FILE?

Definitely don't use the standalone toolchain one. If I'd been consulted when CMake added NDK support they would have never added that flag. It's completely worthless. The only reason standalone toolchains (used to) exist was to ease the use of the NDK with build systems that did not support the NDK. CMake does, so they serve no purpose there.

CMAKE_TOOLCHAIN_FILE I do recommend though, as mentioned in the previous answer. 

• Would using the CMake Standalone Toolchain [1] file way be more convenient and preferable over the 'regular' Cross-Compiling for Android with the NDK [2]?

Both are bad choices. Use the NDK's toolchain file as recommended by the NDK docs. 

• How should setting the include directories be handled?

For NDK headers it's automatic. For your own (or third-party), no differently than you would on any other platform: target_link_libraries. 

• Should I use a find_library() call?

There's no point in doing so for built-in NDK libraries. 

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/752b9973-bb0a-4ba4-ba93-f82af94c06cbn%40googlegroups.com.

[Gabriel Mesias vidal]

Ues

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhtO%2BXv7nV-QswPrZjHZhaD42K7Qzj%2B%3DM8PCCpNROSCW%3Dw%40mail.gmail.com.

[enh]

On Fri, Jul 15, 2022 at 1:51 PM 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:

I've answered this on your SO post mirroring it: https://stackoverflow.com/a/72987366/632035. I'll answer the direct questions here as well:

• Is my general approach correct? Which parts are wrong?

I'd definitely recommend using our CMake toolchain file. The built-in workflow offers no improvements that I'm aware of, and certainly does seem to work less well. We've put in a fair amount of time trying to make it work well, but after years it's still not at parity with our toolchain file.

• Do I need to explicitly set a toolchain file as in a certain android.toolchain.cmake, or is a folder enough or should it also work without providing a CMAKE_ANDROID_STANDALONE_TOOLCHAIN or CMAKE_TOOLCHAIN_FILE?

Definitely don't use the standalone toolchain one. If I'd been consulted when CMake added NDK support they would have never added that flag. It's completely worthless. The only reason standalone toolchains (used to) exist was to ease the use of the NDK with build systems that did not support the NDK. CMake does, so they serve no purpose there.

CMAKE_TOOLCHAIN_FILE I do recommend though, as mentioned in the previous answer. 

can we send a docs fix upstream to make it clear that standalone toolchains aren't really relevant? (i think we've clarified _our_ docs, but i'm assuming the reporter had been looking at cmake's docs?)

 

• Would using the CMake Standalone Toolchain [1] file way be more convenient and preferable over the 'regular' Cross-Compiling for Android with the NDK [2]?

Both are bad choices. Use the NDK's toolchain file as recommended by the NDK docs. 

is there any reason to use the cmake toolchain file (other than legacy uses)? does brad king agree? should we clarify the cmake docs if so?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhtO%2BXv7nV-QswPrZjHZhaD42K7Qzj%2B%3DM8PCCpNROSCW%3Dw%40mail.gmail.com.

[Dan Albert]

Sorry, I had a draft sitting here but forgot to finish and send it.

is there any reason to use the cmake toolchain file (other than legacy uses)? does brad king agree? should we clarify the cmake docs if so?

The motivation for the new approach was to unify the two implementations so that users would get the same behavior whether using CMake's built-in support or our toolchain file. CMake is very much in favor of this approach because they see our legacy toolchain file as an abuse of toolchain files. They were never really intended for implementing support for a platform; they were meant to supply paths to CMake so it could use a compiler that wasn't on your path (I hope I summarized that correctly).

The problem is that so far that hasn't been accomplished without serious behavior regressions. https://github.com/android/ndk/issues/1693 is an excellent example, where using `-DCMAKE_CXX_FLAGS` (which is included in Android Studio's new project template) would prevent your code from being optimized. That's a deal breaker.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAJgzZooe0hLmpufTtJu7WqWBfMrt_h-vse_AEGT1vC9tWkwYPw%40mail.gmail.com.