Sometimes a user may need to invalidate all precompiled
caches and regenerate all platform libraries. For example
this may be necessary after updating Xcode since platform
libraries are generated on basis of Xcode frameworks.
This patch provides a simple setting allowing a user
to manually reinstall a K/N compiler.
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
Without this commit, JVM name mapping logic in BE does not work for FIR,
because FIR cannot use old BuiltInsPackageFragmentImpl descriptor.
In this commit we add our own implementation thus fixing
a pack of FIR black box tests.
This could happen:
* when a common source set had no sources
* when the compile task of a common source set was disabled
In those cases, there were two subsequent failures:
* the metadata JAR could not interpret the missing klib file as ZIP
* the consumer could not read the empty klib in its dependencies
Issue #KT-36674 Fixed
* Add `ResolvedMppVariantsProvider` that provides variant names,
platform artifacts, and metadata artifacts for MPP dependencies
* Rework SourceSetVisibilityProvider.kt so that it uses the
`ResolvedMppVariantsProvider` to determine which source sets should be
read from which metadata artifacts
* Rework `GranularMetadataTransformation` and its consumers so that:
* it uses the
visibility result and extracts the source set metadata from the
host-specific artifacts whenever `SourceSetsVisibilityProvider`
yields host-specific artifacts in the visibility results
* it uses the new Gradle API for resolutionResults / artifactView
* Rework module IDs in the code base, unify the logic of their
construction, also fix possible false-positive visibility in
`applyToConfiguration` that used a module ID that mismatched the
published module ID.
Create the compilations even when all of the targets that the
shared-Native source set is compiled for are disabled on the current
host. In that case, disable the compilation task
Also clear the inputs of the disabled tasks so that when Gradle builds
the task graph it doesn't resolve the dependencies.
Otherwise, a Gradle build that includes the compile tasks of the
disabled targets in the task graph would fail as follows, e.g. on a
macOS host with a project containing a mingw target):
```
Could not determine the dependencies of task ':compileKotlinMingwX86'
...
Could not resolve all task dependencies for configuration
':mingwX86CompileKlibraries'
...
Could not find com.example:my-dependency-mingwx86:1.0
...
Consider host-specific all source sets that participate in a compilation
of a target that cannot be built on some of the hosts.
Exclude those source sets from the `-metadata` artifact since the
`metadata` target must publish in the same way from any host.
Instead, add a metadata variant to those targets which use such a source
set and pack the source set's klib into a similar metadata JAR as the
artifact of those metadata variants.
The JVM IR backend code seems saner to me. The string concatenation
lowering for JVM IR calls the stringPlus intrinsic if there are
only two arguments. That leads to a lot less code:
```
load string
load argument
box argument
call Intrinsics.stringPlus
```
instead of
```
allocate StringBuilder
call StringBuilder.<init>
load string
call StringBuilder.append
load argument
call StringBuilder.append
call StringBuilder.toString
```
This will lead to more boxing, but a lot smaller code. We still
use StringBuilders in JVM IR if there are more than two strings
being concatenated.
Victor Turansky