Restore compiler options DSL for all Kotlin targets. 'KotlinTarget'
interface does not provide any common way to configuring options - this
is the responsibility of related plugin extensions.
From the hierarchical standpoint of view target DSL overrides options
configured in the extension.
^KT-57292 In Progress
Apparently, using such an approach is a popular case especially for
configuring 'dependsOn' parameter. And we should simplify user migration
to more restricted DSL.
^KT-64722 Verification Pending
This should keep compatability with user scripts that for any reason tried to configure 'sourceSets' container inside KotlinTarget, but keep such users warned.
^KT-57292 In Progress
The purpose of this annotation is to distinguish different levels of DSL
in KGP:
- top level extension
- target level DSL
- compilation level DSL
With this marker user should not be able to call implicit methods from
upper levels of DSL, and it should reduce confusion with DSL usage.
^KT-57292 In Progress
To support configuring free compiler arguments for all shared source
sets (KT-61573), we restore 'compilerOptions { }' DSL in the
multiplatform extension.
To avoid user confusion on accidentally using 'compilerOptions {}'
inside Kotlin targets and Kotlin compilations DSL, similar methods with
ERROR deprecation level were added into `KotlinTarget` and
`KotlinCompilation` interfaces. Invoking these interfaces will throw
UnsupportedOperationException. Such an approach works both for Kotlin
and Groove Gradle scripts.
^KT-63491 Fixed
as those experimental APIs have shown to negatively affect usages
of stable APIs (because of resolve confusion), whilst also
failing to address popular use cases.
KT-61636
KT-61355
KT-61368
Unfortunately, there are still problems with running JVM backend tests
with JVM target 21 because:
1) The D8 version that we use does not support bytecode version 21, and
updating to a newer version requires to change JVM target of compiler
tests to 11. This will be addressed separately when we enable JVM 21
in tests-different-jdk.
2) Some tests are failing because of KT-60659 and KT-60770:
- builtinStubMethods/bridgesForStubs/emptyStringListAdd.kt
- jdk/stream.kt
- regressions/kt528.kt
#KT-60662 Fixed
Gradle 8 has removed "validate-external-gradle-plugin" plugin which we
used before to run validate task inputs proper annotations.
With this change, every Gradle dependency that is not published as a
Gradle plugin but uses Gradle API types is also running
'validatedPlugins' task registered manually via a build script.
^KT-59827 Fixed
- Remove 'Target' name from hierarchy components as in
- KotlinTargetHierarchyBuilder -> KotlinHierarchyBuilder
- KotlinTargetHierarchyDsl -> KotlinHierarchyDsl
- Rename KotlinTargetHierarchyDescriptor -> KotlinHierarchyTemplate
To convey a better intuition about the 'template' vs 'layout' separation:
A 'template' is used to 'layout' the actual 'hierarchy' on a given project.
- Move entities from .mpp.targetHierarchy to .hierarchy package
As the .targetHierarchy package was using the 'target' term as well
- Rename SourceSetTree to KotlinSourceSetTree
- Rename SourceSetTreeClassifier to KotlinSourceSetTreeClassifier
(Support external target APIs by introducing a V2 api version)
^KT-58676 In Progress
- This new API will be configurable for 'External Kotlin Targets'
- This change also moves targetHierarchy.android {} into the androidTarget
to avoid potential confusion around the KGP managed AndroidTarget vs
the Google implementation.
KT-58710
Now project level DSL only configures base part of module name, which
latter is enhanced by Kotlin compilation suffix. In this case
'KotlinCompilation.moduleName' is not used.
Additionally,
'KotlinJvmTask.moduleName' usage was deprecated in favor of
'compilerOptions.moduleName'. Though warning is only produced in case
project is using 'org.jetbrains.kotlin.jvm' or
'org.jetbrains.kotlin.android' plugins.
- 'moduleName' is always required to be non-null.
^KT-57688 Fixed
Artem Kobzar