<https://kotlinlang.slack.com/archives/C7L3JB43G/p...

# gradle

[Jeff Lockhart]

https://kotlinlang.slack.com/archives/C7L3JB43G/p1694718667896679

[tapchicoma]

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

[Jeff Lockhart]

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.

[Jeff Lockhart]

https://kotlinlang.slack.com/archives/C7L3JB43G/p1694718760515439?thread_ts=1694718667.896679&amp;cid=C7L3JB43G

[tapchicoma]

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?

[Jeff Lockhart]

It works with 1.9.20-Beta the same as it has in previous versions, at least back to 1.8.

[tapchicoma]

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.

[tapchicoma]

tl;dr it is possible to expand annotations list, but not to shrink

[Jeff Lockhart]

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?

[tapchicoma]

let me think about it

[tapchicoma]

This is the closest I've come up, but it is not the best solution:

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.

[Adam S]

what about accessing the compiler options via the targets, which can be filtered by type?

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("...")
          }
        }
      }
    }
}

[Jeff Lockhart]

@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?

[Adam S]

Ah, good point, I hadn't thought of that. I'm not sure how Kotlin will handle it.

[Jeff Lockhart]

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:

sourceSets.configureEach {
    if (targets.all { it is KotlinNativeTarget }) {
        languageSettings {
            optIn("kotlinx.cinterop.BetaInteropApi")
            optIn("kotlinx.cinterop.ExperimentalForeignApi")
        }
    }
}