Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
Related
The Swift Package Manager (SPM) allows support for different platforms (e.g., iOS, macOS). I'm adapting a Swift library to use SPM, and the need is for some of the code for iOS and macOS to be shared, but to have some differences as well.
I've seen a similar example of this with the Facebook libraries:
https://github.com/facebook/facebook-ios-sdk/blob/master/Package.swift
In that case, they use multiple targets, each with its own (independent) code. This is not an example of platform dependency, rather of target dependency.
I see two paths forward:
1) Have separate library targets for iOS and macOS-- and use a similar approach to Facebook, but the bulk of the code would be shared across the targets. I'm not entirely sure if SPM allows code shared across targets. A downside here is purely in terms of syntactic sugar-- naming differences. It seems unfortunate that you'd have to import say "MyLibrary_iOS" on iOS and "MyLibrary_macOS" on macOS.
2) Have a single target for iOS and macOS, but embed conditional compilation within the source code to conditionally include/exclude specific files. This doesn't have the naming issue as above. But it seems unclean to have to do this conditional compilation.
Any other suggestions?
Thanks!
Wait for the upcoming release of Swift 5.3. This has been added via SE-0273.
I would like to write something like import SignalProtocol at the top of one of my Swift files and then be able to call the C functions from libsignal-protocol-c.
libsignal-protocol-c's README says: "When integrating into actual applications, you should not need anything beyond CMake. Alternatively, you may integrate the code using a build system of your choice."
I think I'd like to use the Swift Package Manager to integrate libsignal-protocol-c into my Swift iOS app. Is there a way to automatically generate a manifest file, ie, Package.swift, and a module map, ie, a module.modulemap file, from libsignal-protocol-c's CMake files? Or if I need to create these files manually, what should they include? Otherwise, how would I do this with CMake?
How to import and use libsignal-protocol-c in an existing .xcodeProj? is a similar question but for Objective-C projects.
I'm not sure its an answer but I'm going to start using https://github.com/christophhagen/LibSignalProtocolSwift. Seems like a good start.
I read this article about Whole Module Optimization (WMO). I am curious if I fully benefit from the optimizations if I place all the swift files from Cocoapods directly in my main project, since then, WMO sees all the swift files as a whole and can make optimizations like function inlining and generic specialization across my whole project, instead of per module (pod).
How does WMO works for multiple pods? Does it do WMO per module/pod? If so, I think a project can benefit even more from WMO if all the swift files are in the same project, since then WHO can optimize everything as a whole, instead of per module/pod. Or am I missing something?
So before going in production, remove all the pods, place the .swift files directly in the project and run WMO looks to me like I will benefit more from WMO than not doing it.
Yes.
Whether it's worth the trouble is another question, but yes to all of it.
(I've done it this way for years, and still do in some projects, but on newer projects I've given up and accepted that frameworks are life and just let CocoaPods be CocoaPods. It's just too much work to do it by hand. But that's opinion. The answer is "yes.")
We are using a Jenkins Shared Library to centralize some code for all our (scripted) pipelines. Now we factored out some Groovy code into a .jar library (written in Kotlin, compiled to be Java 8 compatible). We published this library to our in-house maven repo and now want to use it in our Shared Libary.
We are using #Grab to load our library and up until that point it works like a charm. However we are getting NoSuchMethodError's. We pinpointed it down a bit, we are using OkHttp in our Kotlin lib. OkHttp internally uses Okio. When we call methods that internally call OkHttp-Code from our pipeline, everything is fine. However when the OkHttp-Code call Okio internally, we get a NoSuchMethodError.
We already checked the published .jar file, it contains the classes with the methods that seem to be missing. Does anybody have an idea what the issue could be?
While we are at it, we can't access environment variables set on Jenkins in our Kotlin library, is there a way we can fix this?
We figured it out. The problem was, that a Jenkins plugin used an older version of okio internally. Because plugins and shared libraries somehow share the same classpath, okio did not get loaded and the version from the plugin got used, therefore the class was not present.
We fixed this by repackaging all dependencies in our .jar, so package names would not interfere and we can make sure that our specified dependencies are being used.
Looking the dependencies here you have a few problems:
OKHttp - seems to expect some Android libraries
okio - depends on the Kotlin runtime
Any calls to these will result in method not found errors unless you find a way to make them available without causing problems in Jenkins
I'm building up some Dart code that I would like to use in an app where it is essentially a library to the javascript. I'm wondering how I can specify which Dart files I'd like in the project to be part of the library. For example, theres Foo.dart and Bar.dart. How can I have the created product include both Foo.dart and Bar.dart in one file? I'm also concerned about tree shaking since none of the classes are instantiated in Dart.
There's also a Baz.dart, and I would like to have a different build for compiling Foo.dart and Baz.dart into a single file (though this is less important, as I can accomplish this would separate projects and some symlinking).
Thanks!
This use case (build a JavaScript library with Dart) isn't supported yet.
The reworked js-interop package is supposed to allow to do that but I don't know about it's current state.