Detect when it's really necessary to run commonizer. Resolve Kotlin/Native
platform dependencies. Add dependencies to the proper Gradle configurations.
Note: The most common source sets such as "commonMain" and "commonTest"
should not be used as Native intermediate source sets.
Arguments can be set using a project extra property following the
pattern: `kotlin.mpp.freeCompilerArgsForSourceSet.$sourceSetName`.
Only a compilation's default source set free args are appended to the
compiler args during Gradle builds.
In Kotlin 1.3, we didn't allow setting language version to 1.4. With
the default language version changed to 1.4, it worked because the
language version had only been checked in the setter of the language
settings, and the default value had not been checked.
* Use `maven { setUrl(...) }` in Groovy DSL
* Configure compilation tasks beforehand
in testMppBuildWithCompilerPlugins
* Prevent `gradleSettingsScript()` from failing
when no settings script is found
* Make publishing the compatibility variant optional, and don't publish
the compatibility variant by default -- the library maintainer should
do this explicitly
* To build the compatibility artifact, compile the commonMain source
set using a separate compilation (the default `main` compilation,
while creating a separate `commonMain` compilation; this separation
is needed to be able to still compile *.kotlin_metadata from
commonMain even when compiling *.klib from all source sets)
* When the compatibility variant is disabled, clear the dependencies of
the `main` compilation and disable its Kotlin compilation task
* When the compatibility variant is enabled, exposed it for project
dependencies resolution as well, so that its artifact can be used by
the dependent project instead of the granular metadata artifact that
will contain *.klib (which can't be read by the legacy compiler)
* Refactor the configuration of the metadata compilation dependencies:
concentrate all the logic in one place and make it process the source
sets graph lazily.
As the Kotlin/Native compiler always requires transitive dependencies
to be present among the libraries during compilation, it is necessary
to export the implementation dependencies of Native-shared source sets
as if they were API dependencies.
To do that, add the extendsFrom-relationship between the apiElements
configuration of the metadata target (so that Gradle adds the
dependencies to the transitive dependencies graph) and also add the
dependencies to the project structure metadata (so that the consumer
can find out that it's only their corresponding Native-shared source
sets that need these particular transitive dependencies)
This helps avoid duplicate library names when compiling shared-Native
source sets (the resulting klibs will have a more unique name than just
the source set name which likely repeats between projects)
- Revert back `maven(...)` to `maven { setUrl(...) }`, because in this test this syntax is used intentionally to be valid both for `.gradle` and `.gradle.kts`
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
Separate property needed to prevent Gradle snapshotting absolute paths
as inputs when passed as compiler argument.
To reduce property visibility to external users put it to the impl class
which will make it invisible in completion but still usable in Kotlin
build.
As future some Kotlin/Native compilations in the future may have
different platforms within one target, it's more preferable to
access the konanTarget from the compilation, not its target.
Nikolay Krasko