Check for klib cross compilation support from the KotlinNativeCompilation

[eygraber]

Added to Kotlin for 2.3.20

[hfmehmed]

Can you rebase the PR on main?

[hfmehmed]

Thanks for the contribution.

[omarismail94]

It looks like this change introduces a Gradle Configuration Cache invalidation issue for projects using Kotlin Multiplatform with Kotlin Native targets.

Migrating to kotlinCompilation.crossCompilationSupported causes a configuration cache miss on subsequent builds. e.g.

Calculating task graph as configuration cache cannot be reused because the file system entry '../../out/androidx/room3/room3-common/build/kotlin/kotlin-project-shared-data/crossCompilationMetadata_linuxArm64ApiElements.json' has been created.

[eygraber]

@Tapchicoma is there an underlying issue with the provider, or is it being used incorrectly here?

[hfmehmed]

It's possible that KotlinNativeCompilation object in not serializable, potentially ?

[Tapchicoma]

KotlinNativeCompilation is not serializable

[hfmehmed]

Actually to me it seems that, after the first build KGP creates some file which make the config cache not reusable during the second build.

Calculating task graph as configuration cache cannot be reused because the file system entry 'annotations/build/kotlin/kotlin-project-shared-data/crossCompilationMetadata_linuxX64ApiElements.json' has been created.

@Tapchicoma can you comment on the creation of crossCompilationMetadata_linuxX64ApiElements.json

[AYastrebov]

crossCompilationSupported needs to know whether dependency subprojects have cinterops, so it pulls that information via shared data between projects. Each native target writes a small JSON file (like crossCompilationMetadata_linuxArm64ApiElements.json) into build/kotlin/kotlin-project-shared-data/

[hfmehmed]

The problem is this arifacts is something that is produced by the execution phase. So what seems to be happening is that in the first run (fresh gradle run), Gradle records this json file as a configuration input (but it doesnt exist yet). Then the build executes and the file is created. On the next build, Gradle checks if it can re-use the configuration cache - but it sees that the file now exists which does not match the state it stored before so it invalidates the cache and reruns full configuration.

This is my (possibly wrong?) understanding of what is going on here. Does that have any truth in it?