In Kotlin/Native 1.3.30 EAP1 an ability to build
a static ObjC framework has been added. This patch
adds support for this feature in the kotlin-multiplatform
plugin.
This patch adds a separate Gradle plugin allowing
a user to import Kotlin/Native modules in Cocoapods
projects and use Cocoapods dependencies in Kotlin
code via cinterop.
The plugin when applied does the following things:
1. Add a framework binary for each supported (iOS
or macOS) platform in the project.
2. Add a Cocoapods extension allowing one to configure
Cocoapods dependencies of the project.
3. Create cinterop tasks for each dependency from the
previous point. The tasks are added for main
compilations of each supported platform.
4. Add a task to generate a podspec-file which includes
the framework from the point 1, script to
build it and dependencies from the point 2.
So the Cocoapods import procedure is the following:
1. A user runs `./gradlew generatePodspec`. The plugin
creates a podspec-file with all dependencies.
2. The user adds a dependency on this podspec in his Podfile
and runs `pod install`. Cocoapods downloads dependencies
and configures user's XCode project.
3. The user runs XCode build. XCode builds dependencies and then
runs Gradle build. Gradle performs interop processing and
builds the Kotlin framework. Compiler options and header
search paths are passed in the Gradle from XCode environment
variables. After that the final application is built by XCode.
Issue #KT-30269 Fixed
Earlier we used to have two methods: cinterops(Container.() -> Unit) and
cinterops(Action<Container>). It's OK for Groovy DSL but causes resolution
ambiguity in Kotlin DSL. This patch removes the first overload to avoid
this situation. The second overload still can be called in Kotlin DSL
as `cinterops { ... }`.
In 1.3.20 a new binaries DSL was introduced. This
patch deprecates old DSL methods used for binary
configuration in 1.3.0 and 1.3.1x.
Issue #KT-29998 Fixed
Earlier we added interop libraries built for a main compilation
in dependencies of a corresponding test compilation. But we didn't
add them in dependencies of interop libraries built for the test
compilation. It caused cinterop failures when the test compilation
has interop libraries. This patch fixes it by adding main interop
libraries in dependencies of test ones.
Also earlier interop libraries of test compilations were
unintentionally added in apiElements and publication. This patch
fixes this issue too.
Issue #KT-30290 Fixed
Print a warning with an instruction on how to fix this. Don't warn about
different versions and duplicate plugins in composite build.
Issue #KT-30276 Fixed
The 'java' plugin doesn't expect the 'api' configuration to exist (it
is only introduced by the 'java-library' plugin) and doesn't map it
to the compile scope when publishing with the legacy 'maven' plugin.
This commit adds the missing conf2ScopeMapping for 'api' -> 'compile'
This is needed to ensure that POMs of single-platform Kotlin projects
depending on MPP libraries contain dependencies (Maven coordinates)
of the platform-specific modules of the libraries.
The mechanism and rationale are the same as in KT-28482
Issue #KT-27059 Fixed
This covers the cases when a user knows what they do and doesn't want
anything to do any changes to the POMs, e.g. they want to manually
replace all of the dependencies, so they need the original dependencies.
We are trying to update script dependencies silently when 'Reload script dependencies on file change' is off,
but in case when the queue for update is too long we need to make process visible to user and make it cancelable.
A lookupswitch or tableswitch can be used if all conditions are equality
checks to constants. To be more specific, it can be done if:
1. All conditions are CALL 'EQEQ(Any?, Any?)': Boolean
2. All types of variables involved in comparison are in the same group
of Char/Byte/Short/Int, String or enum.
3. All arg0 refer to the same value.
4. All arg1 are IrConst<*>.
Change-Id: Ifd7cb618395f6c5cc64601018b446f0bb7f5891c
Ilya Matveev