gradle always sees configureCMake and buildCMake tasks as not up to date, even when to files are touched, causing a full rebuild of the cmake target
Intrets
Sergei Zhirikov
Dan Albert
--
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/dc3cfac6-8677-44f5-9edc-2831afa1afe6n%40googlegroups.com.
Rich Schmitt
FWIW, I build an NDK component with cmake inside of Android Studio.
My externalNativeBuild section looks like:
externalNativeBuild {
cmake {
version "3.22.1"
path "path to my source directory"
buildStagingDirectory "./outputs/cmake"
}
}
Perhaps specifying a staging directory makes a difference.
It’s true that it will test build every time, but normally it’s a no-op.
From:
'Dan Albert' via android-ndk <andro...@googlegroups.com>
Date: Monday, June 17, 2024 at 2:27 PM
To: andro...@googlegroups.com <andro...@googlegroups.com>
Subject: Re: gradle always sees configureCMake and buildCMake tasks as not up to date, even when to files are touched, causing a full rebuild of the cmake target
Sergei's reply is correct. Few build systems like to acknowledge that other build systems exist which they might have to cooperate with, so there's no way for a layered Gradle/CMake system to do any better than this.
If the CMake re-run (which is just that: it reruns CMake to determine if anything needs to be done, but it shouldn't need to do any real work, if it's actually recompiling each time, you need to file a bug against AGP at b.android.com, this email won't reach the people that can fix it) isn't something you're able to tolerate in your workflow, the only workaround is to stop using `externalNativeBuild`. Your only other option is to develop your libraries separately and drop them into your project's jniLibs directory for packaging. Theoretically you could use the gradle C++ DSL or nokee or something, but they're not set up for android (and maybe not cross-compiling at all?), so it would take a lot of work to get that up and running. IME putting up with the small extra step of waiting for AGP to ask CMake if there's any work to do is the least painful option.
On Mon, Jun 17, 2024 at 9:58 AM 'Sergei Zhirikov' via android-ndk <andro...@googlegroups.com> wrote:
Yes, Gradle always considers NDK targets not up-to-date. That is intentional, because Gradle has no way of knowing whether those targets are actually up-to-date - that logic is buried inside you CMake files. It's up to CMake to determine what is up-to-date and what needs to be rebuilt. If your project is rebuilt every time, the problem must be in your CMake files. It has nothing to do with Gradle.
On Monday, June 17, 2024 at 4:37:51 PM UTC+2 Intrets wrote:
Hello everyone, I am starting to lose my mind here. This problem makes working with native code essentially impossible. I am using the latest android studio.
I am using CMake like so: https://developer.android.com/studio/projects/gradle-external-native-builds#groovy
As far as I know the oboe samples use it in the same way https://github.com/google/oboe/blob/main/samples/RhythmGame/build.gradle
And these oboe samples also exhibit the same problem.
here these two targets, and more, are never up-to-date and always rebuild. This is more apparent on my own code because it takes a good while to compile.
I have tried poking around with gradle in the command line but I can't even get it to behave just errors like "Could not resolve com.android.tools.build:gradle:8.4.2"
If I go into the .cxx/.../build.ninja folder, I can manually run ninja and it will correctly say it is up to date and nothing needs to be built.
Through my pathalogical liar chatgpt I found some ideas but it all didnt seem to fit. It suggested adding tasks configureCMake and buildCMake to the gradle file and using constructs like inputs.files fileTree(dir: cmakeSourceDir, include: '**/*.cpp', '**/*.h').
I really hope someone can help me, or at least point me into a direction to investigate further.
--
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/dc3cfac6-8677-44f5-9edc-2831afa1afe6n%40googlegroups.com.
--
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/CAFVaGhvThHKgphe4RmhJOjOAP1rnUHja9u%3DUpd78eja8fFzvgQ%40mail.gmail.com.