https://kotlinlang.org logo
#gradle
Title
# gradle
t

tapchicoma

09/15/2023, 10:45 AM
Plugin checker ensures that opt-in is present on shared source sets which itself will require non-native compilations have it. I suspect there is no workaround to pass this checker
j

Jeff Lockhart

09/15/2023, 3:03 PM
The plugin checker is not complaining about the opt-in not being present on the common source set. Is this expected? The code snippet I'm using works to avoid the warning and doesn't result in any other warning or error.
t

tapchicoma

09/15/2023, 3:04 PM
The plugin checker is not complaining about the opt-in not being present on the common source set. Is this expected?
Does it happen with 1.9.20-Beta?
j

Jeff Lockhart

09/15/2023, 3:06 PM
It works with 1.9.20-Beta the same as it has in previous versions, at least back to 1.8.
🤔 1
t

tapchicoma

09/15/2023, 3:12 PM
ah, I was wrong. It is possible to declare additional
optIn
annotations on native and they could not be present on common sources. But vise-versa is prohibited.
tl;dr it is possible to expand annotations list, but not to shrink
j

Jeff Lockhart

09/15/2023, 3:15 PM
Ok, thanks. So there's not a proper typed API then to declare native-only opt-ins only on native source sets to avoid that warning?
t

tapchicoma

09/15/2023, 3:16 PM
let me think about it
👍 1
This is the closest I've come up, but it is not the best solution:
Copy code
targets
        .matching { it.platformType == KotlinPlatformType.native }
        .configureEach {
            compilations.configureEach {
                if (name != KotlinCompilation.TEST_COMPILATION_NAME) {
                    allKotlinSourceSets.forEach {
                        if (!it.name.startsWith("common")) {
                            it.languageSettings.optIn("myOptIn")
                        }
                    }
                }
            }
        }
If you have
linuxX64()
target - approach will configure
nativeMain
,
linuxMain
and
linuxX64
default hierarchy source sets with opt-in. Generally now shared source sets is a grey zone and we need to think how exact DSL to configure compiler options for them should look like.
a

Adam S

09/15/2023, 11:27 PM
what about accessing the compiler options via the targets, which can be filtered by type?
Copy code
import org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget

kotlin {
  targets
    .withType<KotlinNativeTarget>() // find all Native targets
    .configureEach {
      compilations.configureEach { // configure each compilation
        compileTaskProvider.configure { // configure the compilation task
          compilerOptions { // add specific compiler options
            optIn.addAll("...")
          }
        }
      }
    }
}
j

Jeff Lockhart

09/16/2023, 1:14 AM
@Adam S wouldn't that only include the edge target source sets? What about intermediate source sets that are still native-only and also require the opt-in?
a

Adam S

09/17/2023, 8:03 AM
Ah, good point, I hadn't thought of that. I'm not sure how Kotlin will handle it.
j

Jeff Lockhart

09/17/2023, 4:27 PM
The trouble with starting with the target and getting its parent source sets, it's difficult to find where a source set no longer only has native target children without manually excluding source set names. There might be an intermediate source set shared between JVM + native, with common adding additionally JS, for example. Seems there could be some improvement to the APIs to handle this. Maybe if there was an easy way to get the underlying targets that a source set is parent for, something like
targets: List<KotlinTarget>
. Then you could do something like:
Copy code
sourceSets.configureEach {
    if (targets.all { it is KotlinNativeTarget }) {
        languageSettings {
            optIn("kotlinx.cinterop.BetaInteropApi")
            optIn("kotlinx.cinterop.ExperimentalForeignApi")
        }
    }
}
👍 1