Hey. I stuck with multi modules and cocoapods setu...

# multiplatform

[Vlad]

Hey. I stuck with multi modules and cocoapods setup
My shared gradle project added to iosApp as cocoapod dependency.
shared has cocoapods plugin and depends on A which depends on B .
B aslo has cocoapods plugin and depends on pods for internal implementation.
As soon I add any X pod to B 's cocoapods{} xcode build fails with:

<http://Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld|Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld> invocation reported errors

if I don't add any pods into B - all good.
Interesting thing that if I also add X pod into shared cocoapods{} - everything works. Although I really don't want to do that, because X will not be used for all possible builds of the project.

I read similar topics and seems like that setup should be possible.
Could any help to figure out what I am missing. Can I get more descriptive build error out of xcode?

[tapchicoma]

@Andrey Yastrebov could you help here?

[Andrey Yastrebov]

@Vlad can you share a sample reproducer?

[Vlad]

Sure. Sorry for zip, I have limited opportunities on my working mac.
Tell me if your mac can't unzip it, on windows I can't, but on mac all fine.
This project won't build(gradle fine) in xcode with neither xc15 nor xc16.
As soon as you either comment out the added pod from TestDependencyOne or remove comment for the pod in shared, xcode project builds just fine

PodsWithMultimodules.zip

[Andrey Yastrebov]

IIUC you need to use linkOnly flag for shared module. Check the updated project in the attach

PodsWithMultimodules.zip

[Vlad]

linkOnly

Instructs the CocoaPods plugin to use Pod dependencies with dynamic frameworks without generating cinterop bindings.

Does that mean that for dynamic framework (shared.build.gradle -> cocoapods { isStatic = false}) with linkOnly = true for the pod, which is still added into shared , we will have the pod installed, but we will just not have kotlin code generated for it for use.
If that true - that is not great. Because what if we add that pod only conditionally in the TestDependencyOne and the conditional build logic should applied in the library.

And we also will have to know upfront what pods are used in our shared dependencies so you can link them?

[Vlad]

Also couldn't build the updated project just yet, I see there are other changes, but that I will fix tomorrow

[Andrey Yastrebov]

just not have kotlin code generated for it for use

No, the cinterop code will be also available in shared

have to know upfront what pods are used in our shared dependencies

yes