[android] support "make" based ports

[m-kuhn]

Adds support for android builds using make.

Based on previous pull requests

• Fix android ndk clang #21222 (by @holmescn) for the bare minimum to get things working

• [android] vcpkg_configure_make correct set flags for android build #15605 (by @xandox) for the logic to extract variables from using get_cmake_vars

• What does your PR fix?

  Fixes building make based ports using android ndk

• Which triplets are supported/not supported? Have you updated the CI baseline?

  android, no

• Does your PR follow the maintainer guide?

yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

no ports affected

[m-kuhn]

Keen to know if this should be avoided and if yes, how

[holmesconan]

I have cloned the branch fix-android-ndk-clang of opengisch/vcpkg and run vcpkg install libiconv:x86-android for test. the result is sa
config-x86-android-dbg-out.log
config-x86-android-dbg-err.log
d:

$ ./vcpkg install libiconv:x86-android
Computing installation plan...
The following packages will be built and installed:
    libiconv[core]:x86-android -> 1.16#11
Detecting compiler hash for triplet x86-android...
A suitable version of ninja was not found (required v1.10.2). Downloading portable ninja v1.10.2...
Downloading ninja...
  https://github.com/ninja-build/ninja/releases/download/v1.10.2/ninja-linux.zip -> /mnt/wsl/vcpkg/downloads/ninja-linux-1.10.2.zip
Extracting ninja...
Restored 0 packages from /home/holmescn/.cache/vcpkg/archives in 3.5 us. Use --debug to see more details.
Starting package 1/1: libiconv:x86-android
Building package libiconv[core]:x86-android...
-- Using community triplet x86-android. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: /mnt/wsl/vcpkg/triplets/community/x86-android.cmake
-- Downloading https://ftp.gnu.org/gnu/libiconv/libiconv-1.16.tar.gz;https://www.mirrorservice.org/sites/ftp.gnu.org/gnu/libiconv/libiconv-1.16.tar.gz -> libiconv-1.16.tar.gz...
-- Extracting source /mnt/wsl/vcpkg/downloads/libiconv-1.16.tar.gz
-- Applying patch 0002-Config-for-MSVC.patch
-- Applying patch 0003-Add-export.patch
-- Applying patch 0004-ModuleFileName.patch
-- Using source at /mnt/wsl/vcpkg/buildtrees/libiconv/src/1.16-b0c41d3469.clean
-- Getting CMake variables for x86-android-dbg
-- Getting CMake variables for x86-android-rel
-- Configuring x86-android-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:127 (message):
    Command failed: /bin/bash -c "V=1 ./../src/1.16-b0c41d3469.clean/configure --build=x86_64-pc-linux-gnu --host=i686-linux-android \"--enable-extra-encodings\" \"--without-libiconv-prefix\" \"--without-libintl-prefix\" \"--disable-silent-rules\" \"--verbose\" \"--disable-shared\" \"--enable-static\" \"--prefix=/mnt/wsl/vcpkg/installed/x86-android/debug\" \"--bindir=\\${prefix}/../tools/libiconv/debug/bin\" \"--sbindir=\\${prefix}/../tools/libiconv/debug/sbin\" \"--libdir=\\${prefix}/lib\" \"--includedir=\\${prefix}/../include\" \"--datarootdir=\\${prefix}/share/libiconv\""
    Working Directory: /mnt/wsl/vcpkg/buildtrees/libiconv/x86-android-dbg
    Error code: 77
    See logs for more information:
      /mnt/wsl/vcpkg/buildtrees/libiconv/config-x86-android-dbg-out.log
      /mnt/wsl/vcpkg/buildtrees/libiconv/config-x86-android-dbg-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_make.cmake:843 (vcpkg_execute_required_process)
  ports/libiconv/portfile.cmake:29 (vcpkg_configure_make)
  scripts/ports.cmake:142 (include)
...

config-x86-android-dbg-out.log shows that the c compiler does not work. And check the config.log we can see that it is caused by the -l-static-libstdc++ is unknown, which is fixed but deleted by this PR. The original detected CMAKE_CXX_STANDARD_LIBRARIES contains " -static-libstdc++ -latomic -lm" where the -static-libstdc++ is not the standard library link option, and will be transformed by the script. Another problem here is that no --target option is specified, which is critical of cross-compile with clang. It will cause that the linked C/C++ standard library contains unexpected instruments or cause the compiling crash.

[JackBoosY]

Please get failure logs here.

[JackBoosY]

Maybe you should check the port detect-compiler's logs?

[dg0yt]

IIUC -static-libstdc++ is a gcc option which should not be used with clang. If this is what is detected by CMake, then cmake needs more help.
Q: Which android toolchain shall be chainloaded? There is a toolchain file in vcpkg, and there is a toolchain file in the NDK ("upstream"). And there is CMake operation on top of it.

FTR the file from vcpkg does the following:

if (VCPKG_CRT_LINKAGE STREQUAL "dynamic")
    set(ANDROID_STL c++_shared CACHE STRING "")
else()
    set(ANDROID_STL c++_static CACHE STRING "")
endif()

[holmesconan]

Please get failure logs here.

I think it is impossible. Since the PR here is going to fix a community driven triplet that does not covered by the statandard CI pipeline. I could not find any failure logs about Android platform.

[holmesconan]

Maybe you should check the port detect-compiler's logs?

OK, I would like to try it.

[holmesconan]

@dg0yt I found some documentations here:

Warning: CMake has its own built-in NDK support. Before CMake 3.21, this workflow is not supported by Android and is often broken with new NDK releases. Starting from CMake 3.21, the implementations are merged. CMake's built-in support has similar behavior to the NDK toolchain file, though variable names differ. Starting from Android NDK r23, the toolchain file will delegate to CMake's built-in support when using CMake 3.21 or later. See Issue 463 for more information. Note that the Android Gradle Plugin still uses the NDK's toolchain file automatically.

[m-kuhn]

@holmescn this PR only works with NDK <= r21, if possible I'd like to deal with the r23 in a separate PR.

[dg0yt]

Good to know that NDK and CMake are aligning. We can probaly assume building with CMake >= 3.21. (vcpkg ports will use it so users can use it, too.) But I don't think we can always assume NDK >= r23.

[holmesconan]

Good to know that NDK and CMake are aligning. We can probaly assume building with CMake >= 3.21. (vcpkg ports will use it so users can use it, too.) But I don't think we can always assume NDK >= r23.

Yes, more tests found more problems with the older NDK version. More patches needed. Sad.

[holmesconan]

BTW the CMAKE_SYSTEM_VERSION isn't reliable. I have switched to NDK r16 installed by SDK manager and point the ANDROID_NDK_HOME to it. The CMAKE_SYSTEM_VERISON is still 21. And tests on that version shows that the detect_compiler port need help.

[m-kuhn]

IIUC CMAKE_SYSTEM_VERSION is meant to set the "target API level" and does not correspond to the NDK version.

[holmesconan]

IIUC CMAKE_SYSTEM_VERSION is meant to set the "target API level" and does not correspond to the NDK version.

But old NDK do not have new API level. It causes a crash. Since the API level 21 is invalid in NDK r16

[m-kuhn]

I think it's the users responsibility to make sure he has tools (ndk) that handle his settings (target API). What could be done is a warning/error to help point that out and with this help the user fix the mismatch. That would be a nice to have / enhancement.
What I understood from #21831 (comment) is that the CMAKE_SYSTEM_VERSION should be modified based on the installed NDK version, I would strongly suggest against that.

[holmesconan]

I think it's the users responsibility to make sure he has tools (ndk) that handle his settings (target API). What could be done is a warning/error to help point that out and with this help the user fix the mismatch. That would be a nice to have / enhancement. What I understood from #21831 (comment) is that the CMAKE_SYSTEM_VERSION should be modified based on the installed NDK version, I would strongly suggest against that.

That is what I have done in #21847 which give two choices to solve this kind of problem:

1. one can specify the ANDROID_NATIVE_API_LEVEL in the triplet file
2. warning message would be shown in the android toolchain file when detect the compiler flags
   But there are other problems with the detect_compiler port.