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
Victor Turansky