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
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.
for both MPP and single-target projects.
For now, it is only applied to source sets that are connected to 'main'
compilation. It seems fine for all projects except android ones.
There's a way to determine android variant for source set,
but importing android projects seems to be made via other code path.
#KT-36019 Fixed
#KT-37652 Open
Ilya Kirillov