Ehm, Is it since 1.3.30 not possible to use cocoap...
# kotlin-native
j
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")
s
How is CocoaPods related to generating static libs? Could you share your Gradle build script?
j
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
s
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”)“?
j
The project will not create a *.a file when building
So basicly what you are saying, is that if you use the cocoapods plugin, you can no longer build anything else than frameworks.
It also currently block :assemble / :build from being able to complete for other targets
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
a
I can't even build frameworks when using 1.3.30 :/
j
With the cocoapods plugin active, or just in general?
s
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.
@JoakimForslund Have you tried running
linkMainReleaseStaticIOS
Gradle task?
j
@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
If I run it from intellij i'm going to run into missing definition problems
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 🙂
s
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)?
j
Gonna give it a go (adding it as an additional build step)
s
Alternatively you can make e.g.
linkMainReleaseFrameworkIOS
depend on
linkMainReleaseStaticIOS
.
j
Tried that, didnt seem to have any effect
s
What didn’t seem to have any effect?
j
using dependsOn to make the linkReleaseStaticIOS task to run
s
Well, this must have an effect. Have you done this for all variants (debug/release, different iOS targets)?
Because by default debug framework is built.
j
made sure it was under the same target(and debug/release) as the linkDebugFrameworkIOS at least
Ah, the name is apparently
Copy code
linkDebugFrameworkIOS64
and
Copy code
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.
Using dependsOn
s
but not under intellij
It is not supposed to work when using cocoapods plugin.
j
Nah like, i can't refresh because there is nothing named
linkDebugFrameworkIOS64
at that point
Might be able to check before applying it tho if the script is being launched from xcode
and then apply the dependsOn
Ok so, this piece of code can probably and for sure needs to be cleaned up a bit:
Copy code
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
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
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
s
CocoaPods plugin doesn’t create additional targets.
iOS64
is declared in your build script explicitly.
j
Oh ok, so it only adds framework then, and launches only the defined tasks? Since it does not actually run
linkDebugStaticIOS64
s
Yes.
j
Should it not tho? If i added that to the binaries section?
Or is that how its meant to work, aka not like the :build gradle tasks which runs all the steps
i
@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.
@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?
a
I run the build from both xcode and intellij
both fail
i
What was the error? Could you share the project or buildscript?
a
I can share the buildscript, yes
The project one, or the common one?
i
Both of them
Also I think it's better to start a new thread.
a
okay