Hi folks. I was thinking about what the benefit of NOT driving jextract from swift build might be. I think the most significant benefit would probably be that once the swift-java interop is mature enough, an arbitrary Java consumer might want to consume a Swift dependency, and it would be a hurdle if the producer of the library had to apply build plugins for the library to become accessible to Java.
I wanted to see how difficult it would be to jextract an arbitrary SwiftPM dependency, so I translated pieces of our SwiftPM import prototype into a Gradle plugin in the Swift Java repository and adapted it to do jextract instead of Kotlin’s cinterop. I pushed it as a PR in the swift-java repository just as a showcase - PoC SwiftPM import for Swift Java by abdulowork · Pull Request #486 · swiftlang/swift-java · GitHub.
I see that jextract machinery currently operates on Swift sources through swift-syntax and doesn’t perform any type checking, so it doesn't depend on .swiftmodules and .swiftinterfaces as our Objective-C import machinery does. In that case, using SWIFT_EXEC override feels contrived, but I kept it since jextract emits Swift bridges as sources that still need to be compiled, and it makes sense to infer compiler arguments from the compilation of the original sources to compile the bridges. I guess the other option would be to recompile original sources with the Swift bridges.
The linkage model in swift-java is different compared to what we have in Kotlin/Native, and swift-java assumes every Swift module will be in its own image, so I used a SwiftPM hack where you add all dependencies in 2 dynamic products, which forces all transitive products to promote to dynamic libraries as well. The LD dump was anyway useful to link the bridges and to pass library paths to java.library.path and do some DYLD_ env hacks.
Because all of our work on SwiftPM import was based on xcodebuild, this prototype also uses xcodebuild, and thus it only works on macOS.
I wanted to try out some flashy examples of external SwiftPM dependencies, but swift-java produces uncompilable Java and Swift sources, especially around functions like ==, overloads, and anything that touches generics. I managed to fix the Java bridge compilations, but the Swift compilations were too difficult, and I rolled back all these changes. In the end, I settled for a simple randomSample wrapper function from the Algorithms.
What do you think about a use case of applying jextract from an outside Gradle plugin? I am also curious what you think about the SWIFT_EXEC and the LD as ways to introspect the build system.