https://gradle.com/ logo
Join Slack
Powered by
My Google-fu is failing me on "How do I add an opt...
# kotlin-dsl
t
My Google-fu is failing me on "How do I add an opt-in compiler argument for build.gradle.kts compilation?" e.g. 
foo { bar() }
where 
fun bar()
has a 
@RequiresOptIn
, and I don't want to add 
@OptIn(ExperimentalFooBar::class)
on every single usage scattered around in build.gradle.kts files. The only workaround I can think of is to create a wrapping function like: 
fun Foo.barOptedIn() = @OptIn(...) bar()
Am I missing something or is it not possible to globally opt in without changing all the files?
v
can you add file-level optin?
t
without changing all the files?
v
Move the usage to a convention plugin?
t
Still changes all the files, that's pretty much the same as the function I proposed. If bar() has parameters a convention plugin is way more complicated as we need an extension for inputs, etc. It does make sense as workaround, but I still wonder if there's a way to pass compiler args / opt ins.
v
v
Well, if you need compiler options, that is a strong sign that your build scripts are not idiomatic / declarative and you indeed should move the stuff to conventions plugin where you then can easily configure the build-logic build with all compiler options you need. 🙂
t
No, it means that the extension I'm using to configure project-specific declarative configuration has some experimental opt-in properties/functions 😅. I want to opt-in using a global toggle, not having to worry about Kotlin's opt-in annotation at every call site/file. I don't see how wrapping an plugin in a plugin with fully on mirror extensions would make anything more declarative / idiomatic. Is the plugin not idiomatic by using the experimental annotation, or am I missing something?
I guess my answer here is #24221, and otherwise there are multitude of ways of abstracting away the call by mirroring an API without annotations.
v
Ah, I see. Probably quite uncommon that a plugin extension uses opt-in requirements
But if so, yeah, to do it for everywhere you probably have to wait for or send a PR for 24221 or annotate each usage or at least each file
I can't remember ever having seen a plugin extension requiring an opt-in
But maybe a nice idea for some experimental or advanced stuff
t
I guess instead of optin they could use @Incubating, so it doesn't generate a Kotlin compiler warning? (I'm using DSL warnings as errors to find deprecations and problems fast)
v
No idea, would incubating still be shown somehow somewhere?
Except in an IDE annotation
t
I think it's IDE only. Maybe Android Gradle Lint picks it up in CI.
6 Views
Open in Slack
PreviousNext
Powered by