Hi <@U58GRE73J> <@UF0MYLP9Q>, we were discussing the usage of `compileTaskProvider: TaskProvider<Kot...

# multiplatform

[Hakan Mehmed]

Hi @tapchicoma @Anton Lakotka [JB], we were discussing the usage of compileTaskProvider: TaskProvider<KotlinCompilationTask> (https://github.com/JetBrains/kotlin/blob/898f6c0c6988323fb081a5c90d2ea8af56c7f878/[…]/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinCompilation.kt) in the DSL for the kotlin compilations.

Is there any specific reason for exposing a TaskProvider for users instead of some custom dsl block? We in AGP havent had a great experience by exposing task providers before as it leaks task abstractions to the API surface as well as can potentially be misused however wanted to get you view on the reasoning for having a TaskProvider on the API.

[Hakan Mehmed]

tagging some relevant folks here: @Chris Warrington @Jerome Dochez @aurimas

[tapchicoma]

Hi, task provider is exposed for those cases when users want to do low-level configuration for the specific task, though it should be their last resort. Also KotlinCompilationTask is a official API here.

What is your exact concerns with it?

[Hakan Mehmed]

Thanks for the clarification here. I think the main concern is that Tasks in gradle are inherently implementation detail. Having it on the API surface means that every time you change something in the implementation of the task you need to consider the implications of that on the API that the users are exposed to.

[Anton Lakotka [JB]]

compileTaskProvider: TaskProvider<KotlinCompilationTask> this looks more like legacy API that we haven't processed yet.

But I remember we lacked some API to granularly control concrete compiler invocations and thus the compile task provider is the only way to do it.


In general I agree that exposing tasks shouldn't be a default solution.
Maybe we should mark all accessors to the tasks as "delecate api". And / Or detect cases when the task properties has changed by 3rd party (user or other plugins) and warn about it.

[tapchicoma]

@Anton Lakotka [JB] I would discuss it first - I am not sure I agree with you here

[Anton Lakotka [JB]]

Of course, I said maybe 🙂

[Hakan Mehmed]

Hi, curious if there was any discussion had on this topic yet

[Anton Lakotka [JB]]

Not yet 😞

[Hakan Mehmed]

Just an update here. Some internal users of the new plugin are attempting to use the compileTaskProvider to configure the android compilations compile options but we still haven't added support for it on our end. If this API is looking like it will stay for the foreseeable future, I can push for it's adoption on our end. @tapchicoma let me know

[tapchicoma]

Curious why are they using this API and not kotlin.compilerOptions {} DSL? What are their use-case? 🤔

[Hakan Mehmed]

Wouldn't kotlin.compilerOptions {} configure all the compilations for all the targets in the same way.
I recommended them to use kotlin.androidLibrary { compilations.configureEach { compilerOptions {...} } } which works but is deprecated and logs a warning