The sysroot for linux_mips doesn't contain one of platform
libs available for Linux (zlib). So we need to put def-files
to the K/N distribution on a per-target basis instead of putting
a single set of def-files for all targets of the same OS.
Corresponding change in the K/N repository:
https://github.com/JetBrains/kotlin-native/pull/4023
This patch take this change into account at the Gradle plugin side.
Rename raw-fir:common to raw-fir:common -> raw-fir:fir-common.
If there's dependency both on :compiler:visualizer:common and
:compiler:fir:raw-fir:common, only one of artifact is left in classpath
Since 1.4, a regular K/N distribution will not contain prebuilt
platform libraries, so the libraries must be generated at the
user side.
This patch adds support for such generation to the MPP Gradle
plugin. The generation itself is performed by separate utility
provided by the K/N compiler distribution. The plugin checks
existence of platform libraries for required targets and starts
this utility if some some of these libraries are missing. Building
caches for platform libraries is also performed at this step.
The patch also adds some project properties allowing a user to
workaround potential problems. User will be able to:
- Use a special distribution with prebuilt platform libraries.
- Force building platform libraries in the good old sourcecode mode
in case of some issues with the new metadata mode.
Kotlin/Native counterpart: https://github.com/JetBrains/kotlin-native/pull/3829.
Issue #KT-32931 Fixed
Exclude jdk files form libraries input. Instead add jdk major version
to inputs. JavaCompile task acts same to ignore fluctuations in JDK
implementations since api should remain same
Version is written to the plugin.xml in every build so we exclude it to
improve caching.
Add test for kotlin plugin version to checkArtifacts.gradle.kts
Using different incremental setting for KotlinCompile makes impossible
using caches built on CI since it is marked as @Input. Same property for
JavaCompile marked as @Internal.
We do clean checkout now so it shouldn't matter but we want to build
incrementally in some cases for Dev builds on CI.
Compiler version changes every build and makes impossible to reuse
caches for heavy tasks such as compiler proguard. We may fix that by
adding version module directly to the final jar.
Writing build number into a public constant field leads to poor gradle
cache reuse between different builds. Public constant value is a part of
public api and its changes affect inputs of dependent modules.
Extracting build number to resource file allows to ignore it from
runtime classpath which fixes same problem for KotlinCompile tasks
Mikhail Glukhikh