Ehm, Is it since 1.3.30 not possible to use cocoapods plugin and add additional generation of a stat...

# kotlin-native

[JoakimForslund]

Ehm, Is it since 1.3.30 not possible to use cocoapods plugin and add additional generation of a staticLib along side with the framework? Nothing seems to happen at least when you add staticLib to the binaries dsl or using the old outputKinds("static")

[svyatoslav.scherbina]

How is CocoaPods related to generating static libs? Could you share your Gradle build script?

[JoakimForslund]

Its not related but cocoapods plugin seems to add framework to the build automaticly. I would want the iOS code to produce a staticLib along-side with it, but building from xcode does not produce a static library because it does not seem like the link*Debug/ReleaseStaticIOS-task is being started

[JoakimForslund]

@svyatoslav.scherbina https://gist.github.com/Syrou/f74ba447f55b69eb736f41b657d63f7f

[JoakimForslund]

From looking in the https://github.com/JetBrains/kotlin/blob/bdac47369c30ab15984561342109c357c1ec095e/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/targets/native/cocoapods/KotlinCocoapodsPlugin.kt

It seems like it will write over the binaries part with framework and not support if there is other things declared?

[svyatoslav.scherbina]

New cocoapods plugin supports only frameworks currently.
What do you mean by “Nothing seems to happen at least when you add staticLib to the binaries dsl or using the old outputKinds(“static”)“?

[JoakimForslund]

The project will not create a *.a file when building

[JoakimForslund]

So basicly what you are saying, is that if you use the cocoapods plugin, you can no longer build anything else than frameworks.

[JoakimForslund]

It also currently block :assemble / :build from being able to complete for other targets

[JoakimForslund]

I think i'll wait a while with using cocoapods plugin then, fantastic that you've started it, but for now it is a bit too limiting in what it allows, and also hinders normal workflow

[andrew]

I can't even build frameworks when using 1.3.30 :/

[JoakimForslund]

With the cocoapods plugin active, or just in general?

[svyatoslav.scherbina]

So basicly what you are saying, is that if you use the cocoapods plugin, you can no longer build anything else than frameworks.

No, this should not be true.

[svyatoslav.scherbina]

@JoakimForslund Have you tried running linkMainReleaseStaticIOS Gradle task?

[JoakimForslund]

@svyatoslav.scherbina Yes, but since the way things currently are with the pods you need to generate the defination and ceinterop from xcode, and the linkMainReleaseStaticIOS Gradle task will not run from xcode

[JoakimForslund]

If I run it from intellij i'm going to run into missing definition problems

[JoakimForslund]

If I remove the pod(......) things might work I guess, but thats the whole reason for me using the cocoapods plugin in the first place 🙂

[svyatoslav.scherbina]

and the linkMainReleaseStaticIOS Gradle task will not run from xcode

What does prevent you from running linkMainReleaseStaticIOS from Xcode (e.g. as additional build script phase)?

[JoakimForslund]

Gonna give it a go (adding it as an additional build step)

[svyatoslav.scherbina]

Alternatively you can make e.g. linkMainReleaseFrameworkIOS depend on linkMainReleaseStaticIOS.

[JoakimForslund]

Tried that, didnt seem to have any effect

[svyatoslav.scherbina]

What didn’t seem to have any effect?

[JoakimForslund]

using dependsOn to make the linkReleaseStaticIOS task to run

[svyatoslav.scherbina]

Well, this must have an effect. Have you done this for all variants (debug/release, different iOS targets)?

[svyatoslav.scherbina]

Because by default debug framework is built.

[JoakimForslund]

made sure it was under the same target(and debug/release) as the linkDebugFrameworkIOS at least

[JoakimForslund]

Ah, the name is apparently

linkDebugFrameworkIOS64

and

linkDebugStaticIOS64

doing that at least makes it compile under xcode, but not under intellij because the IOS64 target is still named IOS, not sure if this is because of my setup or not tho.

[JoakimForslund]

Using dependsOn

[svyatoslav.scherbina]

but not under intellij

It is not supposed to work when using cocoapods plugin.

[JoakimForslund]

Nah like, i can't refresh because there is nothing named linkDebugFrameworkIOS64 at that point

[JoakimForslund]

Might be able to check before applying it tho if the script is being launched from xcode

[JoakimForslund]

and then apply the dependsOn

[JoakimForslund]

Ok so, this piece of code can probably and for sure needs to be cleaned up a bit:

val isFromXcodeCheck = if (project.properties["kotlin.native.cocoapods.target"] != null) true else false
if (isFromXcodeCheck) {
    tasks {
        "linkDebugFrameworkIOS64" {
            dependsOn("linkDebugStaticIOS64")
        }
    }
}

gradle.taskGraph.beforeTask {
    val numberOfPods = kotlin.cocoapods.pods.size
    if (numberOfPods > 0 && !isFromXcodeCheck) {
        if (this.name.toLowerCase().contains("generatedef") || this.name.toLowerCase().contains("ios") || this.name.toLowerCase().contains(
                "interop"
            )
        ) {
            this.setActions(listOf())
            logger.warn("iOS target needs to be build from xcode in cases when pods libraries are used")
        }
    }
}

but it is basicly needed to still have a sane working experience with the normal gradle tasks in intellij for the other targets (mainly being able to use :assemble and :build)
when using cocoapods with the pods property

[JoakimForslund]

I'd like to suggest that something like this being implemented into the plugin if possible. I think more than me finds it weird that it blocks gradle tasks from their normal behaviour. As for the staticLib setup, I'm guessing the main problem is that the cocoapods plugin adds a target which I didnt add the staticLib to, which by itself is a bit confusing but I do realize the staticLib part of this whole ordeal is probably lack of understanding on my part

[JoakimForslund]

Hmm, does not explain why the linkDebugStaticIOS64 exists tho... which probably indicates that the cocoapods plugin does not respect what I configured on the ios target manually, which I guess it really should

[svyatoslav.scherbina]

CocoaPods plugin doesn’t create additional targets. iOS64 is declared in your build script explicitly.

[JoakimForslund]

Oh ok, so it only adds framework then, and launches only the defined tasks? Since it does not actually run linkDebugStaticIOS64

[svyatoslav.scherbina]

Yes.

[JoakimForslund]

Should it not tho? If i added that to the binaries section?

[JoakimForslund]

Or is that how its meant to work, aka not like the :build gradle tasks which runs all the steps

[ilya.matveev]

@JoakimForslund

Oh ok, so it only adds framework then, and launches only the defined tasks?

Yes, the CocoaPods plugin builds only frameworks needed to use a Kotlin/Native module from Xcode. But it's still possible to run other tasks by adding corresponding build steps in Xcode, modifying the podspec file or configuring dependencies between tasks as @svyatoslav.scherbina proposed.

The plugin neither creates new targets nor overwrites the binary property. It only adds frameworks to all existing Apple targets.

It also currently block :assemble / :build from being able to complete for other targets

it is basicly needed to still have a sane working experience with the normal gradle tasks in intellij for the other targets (mainly being able to use :assemble and :build) when using cocoapods with the pods property

Yes, it's the sad current limitation because we use Xcode project configured by CocoaPods to obtain parameters needed to generate cinterop (like compiler flags or header paths). Probably we will be able to get rid of this limitation in further releases.

[ilya.matveev]

@andrew

I can't even build frameworks when using 1.3.30 :/

Could you please provide more details about your problem? Do you run the build from Xcode?

[andrew]

I run the build from both xcode and intellij

[andrew]

both fail

[ilya.matveev]

What was the error? Could you share the project or buildscript?

[andrew]

I can share the buildscript, yes

[andrew]

The project one, or the common one?

[ilya.matveev]

Both of them

[ilya.matveev]

Also I think it's better to start a new thread.

[andrew]

okay

[ilya.matveev]

https://kotlinlang.slack.com/archives/C3SGXARS6/p1555678337145000