Search for standalone toolchain first

[ayberkozgur]

Currently, ANDROID_NDK has priority over ANDROID_STANDALONE_TOOLCHAIN. As far as I know, there are two main environment setups that NDK devs use :

1. Regular (as untarred) toolchain
2. Standalone toolchain for building and installing private libs into + Regular toolchain on the side out of necessity (for e.g building with Qt for Android)

For people like me who prefer option 2, regular NDK priority over standalone is an inconvenience, due to private installed libs not being found in regular NDK paths, which would be solved by inverting this priority. This inversion does not affect people (probably the majority) who use option 1.

[taka-no-me]

Hi @ayberkozgur, I'm pretty like the current preference of regular NDK over a standalone toolchain. However I find weird that having defined ANDROID_NDK environment variable makes not possible to build with standalone toolchain so I've applied a small patch to fix this behaviour.

By the way I think about complete removal of standalone toolchain support from the cmake toolchain file. I personally don't see any benefits from building with cmake + standalone toolchain when you anyway have a regular NDK. So is there anything except "used to it" that makes you to prefer standalone toolchain?

[ayberkozgur]

@taka-no-me Well, I think most people have ANDROID_NDK and ANDROID_STANDALONE_TOOLCHAIN as environment variables that don't regularly change anyway, so having defined both environment variables makes it impossible to build with standalone toolchain without cmake -DANDROID_STANDALONE_TOOLCHAIN=/path-to-standalone-toolchain or unset ANDROID_NDK, which is a pain to write every time when you are one of the people who prefer the above option 2. My ultimate argument is that those who use standalone toolchain would prefer it over regular NDK and therefore this precedence should be respected in the toolchain file. Those who don't use the standalone toolchain won't even have the environment variable defined in the first place.

About removing the support for standalone toolchain, I'd strongly advise against it. The main reason we use it is because we have projects with a lot of dependencies that we want to build and install into the sysroot of the standalone toolchain before we can build more libraries that are dependencies of further other libraries. This is very clean and easy to use, and it cannot be done with a regular NDK cleanly because it has no real sysroot. ndk-build's dependency handling assumes that all dependencies are built with ndk-build, is definitely not cross-platform and overall quite fugly. These and many other reasons are exactly why we (and probably you) prefer to use cmake in the first place. Without standalone toolchain support, dependency handling would be a mess that requires manual intervention everywhere; or we would have to install dependencies to the plain NDK sysroot ${ANDROID_NDK}/platforms/android-${ANDROID_NATIVE_API_LEVEL}/arch-${ANDROID_ARCH_NAME}, which is not really a sysroot.

[taka-no-me]

It may sound nonsense but you can build with regular NDK and install into the sysroot of standalone toolchain. Unless you mix different variants of STL it should work perfectly fine. It also nicely works with CMake's dependencies as it searches under CMAKE_INSTALL_PREFIX as well as under that long path from your comment.

Long command lines are annoying and as for me CMAKE_TOOLCHAIN_FILE is already too verbose but you either need a flexibility of all parameters or can setup an alias for your daily-use configuration:

alias android-cmake='cmake -DCMAKE_TOOLCHAIN_FILE=/path-to/android.toolchain.cmake -DANDROID_NDK=/path-to-ndk -DANDROID_STL=gnustl_shared -DANDROID_ABI="armeabi-v7a with NEON" -DANDROID_NATIVE_API_LEVEL=16 -DCMAKE_INSTALL_PREFIX=/path-to-standalone-toolchain-sysroot'

[ayberkozgur]

I didn't know CMAKE_INSTALL_PREFIX was also taken as an include/link path; this might be useful indeed. Still, I don't think removing standalone toolchain support is a good idea: It is much simpler and easy to understand compared to the regular NDK and therefore an easier entry point for new programmers. It also more closely resembles other toolchains out there, having isolated a single platform and single architecture. Regular NDK doesn't have this simplicity as it tries to address every single Android hardware out there.

[ayberkozgur]

About the scope of this issue, what is your opinion about the search order of regular vs. standalone toolchains? Also, can you open an issue before removing standalone toolchain support if you ever decide to do it so that other people can discuss this too, since this is quite a big change? Thank you very much.

[taka-no-me]

Indeed the standalone toolchain has simpler inner structure than NDK, but the majority of Android developers is not supposed to deal with NDK internals. Newcomers are not meant neither study NDK structure not learn how to extract a standalone toolchain. They are expected to have cmake+NDK working out of the box.

From my point of view standalone toolchain support is the buggiest and most divergent from mainstream ndk-build part of android-cmake which exists mostly for historical reasons rather than by real need. Currently I don't know any features that are supported with standalone toolchain and are not implemented for regular NDK but the opposite cases do exist. So removal of standalone toolchain related logic will simplify the maintenance and addition of new features.

As for the search order, I'm not going to make any further changes to it (in fact I plan adding more search methods for NDK). If both NDK and standalone toolchain are available then NDK must be chosen.

[ayberkozgur]

I can understand the maintenance considerations, and for our case, CMAKE_INSTALL_PREFIX solves the main issue (we probably also don't need a standalone toolchain at all, just a detached sysroot would be enough). Still, I would open an issue to discuss this removal with others as well.

Closing this issue.