Closed finagolfin closed 1 month ago
Many build systems likely simply set that CMAKE_SYSTEM_NAME/CMAKE_SYSTEM_VERSION/CMAKE_SYSTEM_PROCESSOR triad to compile for all platforms, just setting CMAKE_ANDROID_NDK additionally for Android. It would be good to continue supporting that basic CMake config.
I really can't recommend doing this. There's a reason we have a toolchain file. We've never gotten CMake to behave the way we want it to without one. More time invested would certainly be able to work that out, but we invested quite a lot already and have nothing to show for it. It isn't something we can afford to spend time on for the foreseeable future.
I looked into that error and the problem is that CMake expects NDK_PROC_aarch64_ABI and so on to be set, but the new abis.cmake no longer does:
Ugh. It looked unused so I removed it while doing some related work (I think we didn't know what the correct value was for rv64, and since it appeared unused it was simpler to just remove than it was to figure that out). Didn't realize that was for CMake interop. I'll put that back and add a comment...
Is [abis.json] generated externally somewhere?
Yes, it's generated from meta/abis.json as part of the NDK's build process.
https://android-review.git.corp.google.com/c/platform/ndk/+/3196345 should fix it. Like I said above though, I really don't recommend using CMake this way for the NDK. We don't test that workflow, and that work was never finished. It was supposed to reduce maintenance costs for us and CMake, and make things easier for users, but the result was the opposite for everyone, so for now we have no plans to pick it back up.
I really don't recommend using CMake this way for the NDK. We don't test that workflow, and that work was never finished.
Understood, but realistically there are a lot of CMake projects that use that original set of config options, that predates toolchain files, who are never going to migrate over to toolchain files, until forced to. That's why I asked if this was a choice, to force people to stop using that original basic config.
In my case, I hit this when testing my Android SDK for Swift with the new NDK, but the Swift project is slowly moving to toolchain files anyway, swiftlang/swift#38124. I suspect most projects won't, until forced to.
Understood, but realistically there are a lot of CMake projects that use that original set of config options, that predates toolchain files
FWIW, for Android, our CMake toolchain file actually does predate the built-in CMake support, and the 3p toolchain file ours is based on predates it by years. If CMake had built-in support for Android before we went that route, we definitely would not have bothered.
That's why I asked if this was a choice, to force people to stop using that original basic config.
Well, it's somewhere on the edge of supported and unsupported. Like I said, we don't test this configuration, and we know it doesn't work as well as the toolchain file (where "well" means that it uses all our recommended configuration options; if what you actually want is for your build config to most closely match the defaults for other CMake platforms, the built-in behavior works better for that). We'll fix issues as they're reported, but until we've got people to spare to make this work properly, it's going to have a lower standard of support (from us) than the toolchain file workflow.
I suspect most projects won't [move to toolchain files], until forced to.
IME, most projects are already on toolchain files for Android. I don't know the last time I ran into a project that wasn't using them. They're certainly out there, but Android's docs have always recommended our CMake toolchain file, and until CMake 3.7 the toolchain file (ours or the 3p one) was the only option.
I went to write a test for the fix, and I noticed that the premise of this report (using CMAKE_SYSTEM_PROCESSOR
) isn't actually the interface that CMake documents for Android. https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-android-with-the-ndk doesn't seem to mention CMAKE_SYSTEM_PROCESSOR
and says to use CMAKE_ANDROID_ARCH_ABI
. I'm not sure CMAKE_SYSTEM_PROCESSOR
is future-proof, since one processor can support many ABIs. A much older version of the CMake toolchain file for Android in fact had several ABIs for CMAKE_SYSTEM_PROCESSOR=armeabi-v7a
. That's gone now, but had 16k page sizes been a new ABI (in a lot of ways, that is a new ABI), CMAKE_SYSTEM_PROCESSOR
also wouldn't have been enough to specify the target. It's a bit too early to say if riscv64 will reintroduce that problem, but there are a lot of hardware variations for that architecture.
I'll still put those values back because it's trivial, but the test I'm adding is only going to cover the documented interface.
Even if you don't want to migrate to the toolchain file, you probably should migrate to the documented CMake interface. OTOH, CMake's pretty good (very good, in fact) about keeping backwards compat even for accidental stuff, so maybe not something that'd ever be a problem.
Broke on Windows. I think it's just a test issue, but reverting until I can debug.
Round 2 stuck: https://r.android.com/3213881. r28 (currently trunk) is fixed. Will cherry-pick to r27b (I'm waiting for some compiler fixes before that goes to QA, but hopefully shouldn't be long).
Maybe the following information can be interesting: https://bugreports.qt.io/browse/QTBUG-127468 https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9766
Is there any idea when NDK 27b will be published?
Is there any idea when NDK 27b will be published?
As soon as we're able. Infrastructure's broken.
(in the mean time, keep using r26d?)
Yes, we keep using r26d on our stable branch but we also started to use r27 in the dev branch. Currently we use a "hack" in our toolchain file until CMake 3.30.3 is published to work with r27:
if(ANDROID_NDK_REVISION VERSION_EQUAL "27.0.12077973" AND CMAKE_VERSION VERSION_LESS "3.30.3")
set(NDK_PROC_aarch64_ABI "DUMMY")
set(NDK_PROC_armv7-a_ABI "DUMMY")
set(NDK_PROC_i686_ABI "DUMMY")
set(NDK_PROC_x86_64_ABI "DUMMY")
endif()
This is possible for us because we set CMAKE_ANDROID_ARCH_ABI. In this case CMake currently requires the values but do not use them.
You could also delete your hack and switch to using CMAKE_ANDROID_ARCH_ABI
like the CMake docs say? Or using the toolchain file?
As far as I know a toolchain file is a way to provide information for cross-compiling early in the CMake run. But it looks like it is also possible to provide all information in command line parameters like @finagolfin described. So I think this is not relevant here.
In general it is possible to set CMAKE_ANDROID_ARCH_ABI
so NDK_PROC_*_ABI
and NDK_ARCH_*_ABI
are not used.
But with CMake <= 3.30.2 they are expected anyways. That is, what https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9766 would change -> Only expect when use.
When CMAKE_ANDROID_ARCH_ABI
is not set CMake try to determine it:
CMAKE_SYSTEM_PROCESSOR
is given NDK_PROC_*_ABI
is used._ANDROID_SYSROOT_ARCH
is given NDK_ARCH_*_ABI
is used.It looks like there was also a time when the NDK did not provide this information before because CMake has also a function to set it by its own: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9766/diffs#60c1329725f8668d3f59d64323770918b100780a_321_321 (Line 321++ is not directly visible at loading).
As far as I know a toolchain file is a way to provide information for cross-compiling early in the CMake run. But it looks like it is also possible to provide all information in command line parameters like @finagolfin described. So I think this is not relevant here.
See https://developer.android.com/ndk/guides/cmake (specifically the "caution" section under "The CMake toolchain file"). It's very relevant. We only provide best-effort support for the workflow you're using.
Description
This simple command always worked in the past for most CMake repos:
For example, with NDK 26d:
I looked into that error and the problem is that CMake expects
NDK_PROC_aarch64_ABI
and so on to be set, but the newabis.cmake
no longer does:I looked in the source for this file, but it's not there and saw no mention of it in the scripts either. Is it generated externally somewhere?
Was dropping these a mistake or a choice? If I add back
NDK_PROC_aarch64_ABI
, the config works again.Many build systems likely simply set that
CMAKE_SYSTEM_NAME
/CMAKE_SYSTEM_VERSION
/CMAKE_SYSTEM_PROCESSOR
triad to compile for all platforms, just settingCMAKE_ANDROID_NDK
additionally for Android. It would be good to continue supporting that basic CMake config.Affected versions
r27
Canary version
No response
Host OS
Linux
Host OS version
Fedora 40 x86_64
Affected ABIs
armeabi-v7a, arm64-v8a, x86, x86_64
Build system
CMake
Other build system
No response
minSdkVersion
21
Device API level
No response