For cocoapods plugin can we set additional export ...
# multiplatform
d
For cocoapods plugin can we set additional export frameworks?
k
I was curious about that as well. didn't spend the time to investiate yet.
h
cc @ilya.matveev
i
Yes, it's possible. The plugin creates both debug and release frameworks by default so you can access them and configure exports you need. E.g.
Copy code
iosX64("iOS") {
    binaries.getFramework("RELEASE").export(project(":exported"))
}
k
is that also possible for frameworks that are brought in via cinterop?
i
What do you mean by frameworks brought in via cinterop?
d
@ilya.matveev this code tries to create new one framework. And cocoapods plugin shows error that framework name is dublicated
Anyway, if you set another name for this framework, podspec file exports original framework without external projects
i
this code tries to create new one framework
@Dmitry Motyl It shouldn't. Could you share a link to your buildscript?
d
Copy code
apply plugin: 'kotlin-multiplatform'
apply plugin: 'kotlin-native-cocoapods'

version = "1.0"

kotlin {
    targets {
        fromPreset(presets.jvm, 'android')
    }

    sourceSets {
        commonMain.dependencies {
            api project(':domain')
            api project(':networking')
        }
    }

    iosX64("ios").binaries {
        framework {
            export project(':domain')
            export project(':networking')
        }
    }

    cocoapods {
        summary = "..."
        homepage = "..."
    }

}
I get error:
Cannot create binary debugFramework: binary with such a name already exists
if I set
Copy code
iosX64("ios").binaries {
        framework("shared") {
            export project(':domain')
            export project(':networking')
        }
    }
It creates new one framework but cocoapods dependency export original framework without ‘domain’ and ‘networking’
k
Copy code
iosX64("ios") {
        compilations.main {
            cinterops {
                phonenumbers
            }
        }
        binaries {
            framework("$ios_framework_name")
        }
    }
'phonenumbers' is an Obj-C framework
i do also notice that the cocoapods plugin creates 'debugFramework' and 'releaseFramework', so I end up with duplicates
i
@Dmitry Motyl Yes, the
framework()
call does create a new framework. To configure already existing one, use the
getFramework()
method I've shown above.
@Kris Wong No, the plugin have no DSL allowing exporting declarations generated by cinterop. But why do you need to do it? A library you want to interop with should be accessible from ObjC/Swift without building an intermediate Kotlin/Native library.
d
@ilya.matveev In your example You get access to “release” framework. Can I configure both “release” and “debug” in one-line code?
i
There is no such option in plugin's DSL but you can use Gradle's standard
configure
method:
Copy code
linuxX64("linux") {
    binaries {
        val release = getExecutable("RELEASE")
        val debug = getExecutable("DEBUG")
        configure(listOf(release, debug)) {
            /* Configuration. */
        }
    }
}
👍 1
k
I actually used
vendored_frameworks
within the generated podspec to export the framework binary
it works nicely
i
I see. It looks like we have some confusion of concepts here. I was telling about exporting other Kotlin/Native modules in a framework as described here: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#building-final-native-binaries (see the
Exporting dependencies in frameworks
section). It's technically possible to export Kotlin declarations produced by cinterop for a native library too but such an export doesn't make much sense. While you mean exporting a native framework in terms of CocoaPods by adding it to
vendored_frameworks
. The plugin doesn't provide such a DSL but you alway can post process the podspec file generated by the plugin. You can write your own task that modifies the
vendored_frameworks
field and register it as a finalizer for the
podspec
task (see https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:finalizer_tasks).