We have huge issues with the build times (now at 2...

# kotlin-native

[Waldemar Kornewald]

We have huge issues with the build times (now at 2:30 hours) because we have to build different SDKs from the same monorepo. These SDKs share the same underlying modules (i.e. shared APIs) and these shared APIs be compatible between those SDKs. However, publishing fully separate XCFrameworks leads to duplicate copies of the same shared APIs such that they become fully separate and incompatible duplicate APIs. That’s why we resort to workarounds like building different combinations of SDKs (A + B + C, A + B, A + C, B + C, A, B, C) each as a single combined XCFramework. Of course this blows up build times and we have to be careful which combinations are actually needed in practice.

Now to my feature request: Would it be possible to build the whole repository into a set of multiple XCFrameworks (e.g. one XCFramework per Gradle/KMP module) which depend on each other in the same way as the Kotlin modules depend on each other? Then we could build every module exactly once and use just the necessary subset of those XCFrameworks in each app. If this is not an option for the Objective-C export, could you please at least consider doing this for the Swift export?

[Waldemar Kornewald]

@Pavel Kunyavskiy [JB] do you maybe know if there’s any internal discussion around making native (and JS/WASM) exports more closely match the module structure (same as what already happens on JVM)?

[Pavel Kunyavskiy [JB]]

cc @sergey.bogolepov

[sergey.bogolepov]

Hi!

Would it be possible to build the whole repository into a set of multiple XCFrameworks (e.g. one XCFramework per Gradle/KMP module) which depend on each other in the same way as the Kotlin modules depend on each other?

It is not supported at the moment, and we don't have immediate plans to support such feature.

On the other hand, compilation times are indeed painful and we plan to focus on them as soon as possible.

[Waldemar Kornewald]

Is this split-per-module solution something you would consider in the next 1-2 years though? This could at least for us massively reduce build times to around 30min or even less since each tiny XCFramework could be built in parallel (also something that doesn't happen currently) and each module would consume much smaller amounts of RAM than these monolithic monster XCFrameworks. I measured that the clang subprocess alone can take 15-20 GB RAM per XCFramework (while using only 1 CPU core, same as the JVM process).

And building everything in parallel on different CI nodes (Gradle seems to prevent parallel execution otherwise) would thus consume more than 100GB of RAM for a single build. We'll have to massively increase the CI resources just to get to 30min build times this way.

Of course improving compilation times in general would also be great. Our number of XCFrameworks just keeps growing faster than the compiler speedups.😅

[sergey.bogolepov]

Is this split-per-module solution something you would consider in the next 1-2 years though?

Again, no such plans at the moment. Our end goal is to drastically improve compilation times, and not provide "split-per-module solution". It might be an implementation detail of the compilation time improvement (or it might not).

[Waldemar Kornewald]

Alright, thank you

[Waldemar Kornewald]

I've done a little test with the experimental Swift export and that generates separate .o files per module. If you don't intend to provide the split-per-module solution, maybe we could actually build something on top of those .o files ourselves if the final stable Swift export still has them?