Status Update
Comments
vm...@google.com <vm...@google.com> #2
As already explained on GradleTaskFinderWorker
represents a guessing list since on studio we don't have the full list of tasks as an optimization for the sync process, meaning this may potentially result on undefined tasks, throwing the above exception.
Those are the tasks generated for each module given the attached KMP project:
module='p1', tasks=[assembleDebug, assembleDebugUnitTest, assembleDebugAndroidTest]
module='p1.iosArm64Main', tasks=[assemble, testClasses]
module='p1.iosArm64Test', tasks=[assemble, testClasses]
module='p1.iosSimulatorArm64Main', tasks=[assemble, testClasses]
module='p1.iosSimulatorArm64Test', tasks=[assemble, testClasses]
module='p1.iosX64Main', tasks=[assemble, testClasses]
module='p1.iosX64Test', tasks=[assemble, testClasses]
module='p1.appleMain', tasks=[assemble, testClasses]
module='p1.appleTest', tasks=[assemble, testClasses]
module='p1.commonMain', tasks=[assemble, testClasses]
module='p1.commonTest', tasks=[assemble, testClasses]
module='p1.iosMain', tasks=[assemble, testClasses]
module='p1.iosTest', tasks=[assemble, testClasses]
module='p1.nativeMain', tasks=[assemble, testClasses]
module='p1.nativeTest', tasks=[assemble, testClasses]
module='p1.main', tasks=[assembleDebug]
module='p1.unitTest', tasks=[assembleDebugUnitTest]
module='p1.androidTest', tasks=[assembleDebugAndroidTest]
There are different considerations here:
- Our
MakeGradleProjectAction.doPerform
consider all the project modules but this can be optimized by discarding the ios, native and apple ones since Studio shouldn't consider those at all during build. - On
GradleTaskFinderWorker.findTasksForModule
thecommonMain
andcommonTest
are considered asisGradleJavaModule
for this reason there are two tasks that are always created for java modules which isassemble
representing the build mode and thetestCompile
, which in this case isn't available. - We should have a proper integration test coverage of
GradleTaskFinderWorker.findTasksForModule
mechanism since is quite sensible to generate unexpected tasks
ga...@google.com <ga...@google.com> #3
Can MakeGradleProjectAction.doPerform
only provide tasks for Android modules, and rely on the platform to provide the remaining ones?
vm...@google.com <vm...@google.com> #4
If not bad remember IntelliJ relays heavily on having all the tasks available but I can double check this
vm...@google.com <vm...@google.com> #5
What suggested on TasksExecutionSettingsBuilder
.
Below I shared the different tasks executed using platform ProjectTaskManager.getInstance(project).buildAllModules()
method that is triggered on IDEA with pressing build
, which shows clearly what described previously.
Configured gradle tasks = false
Executing tasks: [:p1:compileDebugSources, :p1:compileDebugUnitTestSources, :p1:compileDebugAndroidTestSources]
Configured gradle tasks = true
Executing tasks: [:p1:assemble :p1:iosArm64MainBinaries :p1:iosArm64TestBinaries :p1:iosSimulatorArm64MainBinaries :p1:iosSimulatorArm64TestBinaries :p1:iosX64MainBinaries :p1:iosX64TestBinaries :p1:linkIosSimulatorArm64 :p1:linkIosArm64 :p1:linkIosX64]
The fact that studio is "guessing" that tasks names to build for each module, may end up in this situation in the case those are not present. For this reason there are two potential options to address this:
-
Option 1
- For the KMP projects when build the entire project just run
assamble
andcheck
tasks. This will delegate the responsibility to different created Gradle tasks and its dependencies to run, meaning that as a good practice abuild
task for the module should depend onassemble
, similar totest
task should depend oncheck
.
- For the KMP projects when build the entire project just run
-
Option 2
- The skip configuring all tasks logic for studio doesn't still create a few of the related to project tests. We can potentially, reuse this by populating the build task for the module making the existing platform mechanism to work
Option 2
, has many cons linked to performance but also to the fact that this will not be consistent with android projects where those tasks will not be displayed. At addition, the selection of the build task isn't trivial and may not be aligned with the one expected by the platform, resulting in inconsistencies.
sp...@google.com <sp...@google.com> #6
Are
sp...@google.com <sp...@google.com> #7
From
In fact, I think that Iguana not only added those testClasses tasks in its "Make Project" task execution list, but also others that it shouldn't like: linkDebugFrameworkIosArm64 (I build on an MacBook with Apple Silicon). In other words, for KMP projects, the list of tasks being build by Iguana for "Make Project" contains many tasks that shouldn't (and Hedgehog didn't).
(I'm not sure if that is a separate bug or has the same underlying cause as this bug)
ge...@gmail.com <ge...@gmail.com> #8
(I'm not sure if that is a separate bug or has the same underlying cause as this bug)
I am wondering the same, so I tried "Make Project" with both latest Hedgehog and Iguana.
Hedgehog's output was effectively:
Executing tasks: [
:<app-module>:assembleDebug
]
Iguana's, though, was:
Executing tasks: [
:<kmp-module-a>:assemble,
:<kmp-module-a>:assembleDebug,
:<kmp-module-a>:assembleDebugAndroidTest,
:<kmp-module-a>:assembleDebugUnitTest,
:<kmp-module-a>:testClasses,
:<kmp-module-b>:assemble,
:<kmp-module-b>:assembleDebug,
:<kmp-module-b>:assembleDebugAndroidTest,
:<kmp-module-b>:assembleDebugUnitTest,
:<kmp-module-b>:testClasses,
:<android-module-a>:assembleDebug,
:<android-module-a>:assembleDebugAndroidTest,
:<android-module-a>:assembleDebugUnitTest,
:<android-module-b>:assembleDebug,
:<android-module-b>:assembleDebugAndroidTest,
:<android-module-b>:assembleDebugUnitTest,
... // for every module of the app!
]
Task linkDebugFrameworkIosArm64
doesn't appear anywhere in that list, but task assemble
depends on a number of arm64-related tasks:
$ ./gradlew :<kmp-module-a>:assemble --dry-run | grep Arm64
... // dependency modules
:<kmp-module-a>:compileKotlinIosArm64 SKIPPED
:<kmp-module-a>:compileKotlinIosSimulatorArm64 SKIPPED
:<kmp-module-a>:iosArm64MetadataJar SKIPPED
:<kmp-module-a>:iosSimulatorArm64MetadataJar SKIPPED
vm...@google.com <vm...@google.com> #9
Thank you, for pointing this out +1
, keeping just one opened for the described issue. As already mentioned workaround, feel free to define the required task testClasses
for the affected modules on the Gradle build file, while we addressing this issue in Android Studio. Thank you
task("testClasses").doLast {
println("This is a dummy testClasses task")
}
Description
Usinghttps://github.com/sellmair/kotlin-multiplatform-projects/tree/IDEA-348814/Android-Studio-Iguana-breaks-KMP-compilation with J latest canary.
Running make project executes:
which fails with
Cannot locate tasks that match ':p1:testClasses' as task 'testClasses' not found in project ':p1'.
.