I'm noticing that quite a few useful Kotlin compil...

# gradle

[ankushg]

I'm noticing that quite a few useful Kotlin compiler arguments exist that haven't yet made their way into the Gradle DSL.

As a result, we have a lot of things split between freeCompilerArgs vs kotlinOptions

Is there a philosophy on which CLI args should be configurable via gradle properties vs which ones shouldn't? Are there docs on which flags are more experimental than others?

I initially assumed that maybe only stable things make it into the Gradle DSL, but I'm also seeing a few experimental things available in there too (e.g., KotlinCommonOptions.useFir)

I mostly want to avoid spamming youtrack tickets or PRs for every little CLI arg if there's a process that's being followed that I just don't know about 😅

[gammax]

I’m also curious about this. We had a discussion about compiler arguments in the Detekt repo and this uncertainty makes things a bit harder for us. Would be cool if someone from #compiler could chime in.

[tapchicoma]

Generally I wanted for some of the future releases (~1.7.0) to migrate kotlinOptions { ... } into Gradle properties api (should simplify life inside the Kotlin plugin). Could also look what additionally should be available in the DSL.

Generally I would say all non-experimental options that make sense to expose in Gradle DSL should be available in DSL.

You could add in this thread name of options that are missing and should be explicitly exposed via DSL.

[mbonnin]

Why not exposing experimental options too with an Opt-In marker?

[mbonnin]

I guess groovy might be an issue cause it doesn't support this....

[mbonnin]

But if there'd be a way to add it only for Kotlin build script, I'd love this to be discoverable in the IDE

[tapchicoma]

we will discuss if it is possible. Probably worth to drop at all freeCompilerArgs and provide proper DSL for each compiler option.

[mbonnin]

Maybe hints can be passed to Groovy callers through naming, i..e all experimental flags should start with experimental (which is maybe already the case?)

[ankushg]

one that i'd like to see for JS is -source-map-base-dirs