Do you have any advice on how to move forward with this?
I had hoped for a few more comments from other maintainers on whether supporting a non-Apple Objective-C runtime is worth the added complexity and maintenance burden. I realize it’s a niche use case and the number of users will likely be small. If the (core) Swift team does not see enough value in cross-platform Objective-C interop — regardless of how it’s implemented -– it would be good to know before investing further effort or working on a prototype.
As I understand it, both swift-corelibs-foundation and Darwin Foundation currently embed swift-foundation, which includes the types that have been reimplemented in pure Swift; swift-corelibs-foundation and Darwin Foundation have wrappers around the swift-foundation types, and have their own implementations of types that have not been reimplemented in swift-foundation.
We could provide a fork of GNUstep Base which is similar to the current Darwin Foundation, i.e. it wraps swift-foundation for the types that have been implemented by it. Then, this could become another library-combo for GNUstep. Alternately, we could provide a solution more similar to the pre-swift-foundation Darwin Foundation, where Swift wraps around the pure-ObjC GNUstep Base. Including Swift code in Base is probably not viable, because GNUstep still wants to be very portable and even support targets that only have GCC and not LLVM support. (This might change in the future.)
Can you analyse thouroghly the request that is made in the first link above (swift forum)
It is about bridging from Swift to ObjC on non Apple plattforms.
Likely needed is the inclusion of gnustep/libobjc2 into the Swift compiler and runtime.
Please determine what efforts are necessary to implement the wanted feature. Make a detailed plan for this based on the code you find in the linked repositories, with needed milestones and steps in these milestones.
and got this answer, which I think is a good first estimation from which to start:
Has anyone at minimum started to fork the projects required to start experimenting? I am looking to move some of my monthly donations to a new projects and once I see a central GitHub repository form and some progress made, I would like to do that. I think more people would get involved if they saw the basics start to emerge.
Perhaps choose a title for the mission (SwiftStep or something), starting the GitHub, choosing an initial strategy to attempt would go a long way to establishing seriousness.
I see that Swift and GNUStep’s libobjc2 would need forking. And perhaps choosing an initial distribution to test it on that already uses GNUStep as the main GUI like gs-desktop (or my favorite nextspace) or eventually and probably the goal Gershwin which is getting a lot of attention right now. These would all be good testing environments
Built a Swift 6.3 Linux toolchain against that environment.
Built a small demokit where Swift imports a Clang module containing a GNUstep Objective-C class and calls Objective-C methods using Foundation objects.
The smoke test currently does this:
import ObjCDemoKit
guard let greeter = MakeObjCGreeter() else {
fatalError("ObjCGreeter allocation failed")
}
greeter.logFoundationObjects()
if let message = greeter.messageCString() {
print("Swift saw:", String(cString: message))
}
print("Swift saw item count:", greeter.itemCount())
The Objective-C side uses NSObject, NSString, NSArray, NSLog, ARC, and Blocks.
Output:
ObjCGreeter: Hello from GNUstep Objective-C (4 items)
Swift saw: Hello from GNUstep Objective-C
Swift saw item count: 4
Important caveat: this is not "Swift supports GNUstep ObjC interop now." It is a bootstrap smoke test with explicit shims so we can identify the real porting surface.
The most obvious Swift-side work items so far are:
IRGen needs a real GNUstep ObjC ABI mode.
Swift currently emits Darwin-style class references like OBJC_CLASS_$_Foo.
GNUstep/libobjc2 exports symbols like ._OBJC_CLASS_Foo.
Selector references need GNUstep/libobjc2-compatible emission or registration.
Swift currently emits Darwin-style objc_selrefs.
The demo temporarily registers those at startup with sel_registerName.
The Swift runtime ObjC metadata entry points need to be compiled/adapted for GNUstep.
The demo currently shims swift_getObjCClassMetadata, swift_getObjCClassFromMetadata, and objc_opt_self.
Proper wrapper metadata support still needs to live in the Swift runtime.
Runtime/Foundation headers need more careful isolation.
Forcing SWIFT_OBJC_INTEROP=1 globally in the Swift runtime exposed GNUstep Foundation/CoreFoundation C++ include compatibility issues, so that needs a more surgical approach.
Current status: baseline runtime/Foundation/CoreBase builds, Swift 6.3 toolchain builds, and a minimal imported Objective-C GNUstep class can be called from Swift with demo-side ABI shims.
I'll clean this up into a public repository once the bootstrap scripts and notes are in a useful shape.
I'm reading the thread bit by bit. Not sure if it's been mentioned, but a problem I once noticed with GNUstep "feasibility" was licensing: the library is (L)GPLv2. It might be something worth considering. Sorry in advance if my comment is completely OT. =)
license concern is valid, but it should not make all apps built with the toolchain open source as long as GNUstep remains an optional dynamically linked LGPL runtime dependency; the compliance burden is notices/source/relinkability for the GNUStep libraries, not relicensing the app IMO. The risk/concern is the same if you are using GNUStep alone.
Perhaps choose a title for the mission (SwiftStep or something), starting the GitHub, choosing an initial strategy to attempt would go a long way to establishing seriousness.
I created a OpenSwiftProject org and fork the repos to start working on it. @austintatious .
I can't give you the accurate answer. I have a 1T Mac with 500G+ free space. And my recommendation is 100GB~200GB the same space as you build a normal Swift toolchain.
I finally had time to build this. And I am astonished. I got to playing with it and I just couldn't believe how easily it worked. I know there is a lot more to get done, but this is fantastic. Just the fact alone that we can message an ObjC class and get results back (even if we're not bridging to Swift) is incredible.
I am interested in playing around with GNUStep's AppKit.
If you decide to open up donations on GitHub, I will sponsor (nothing extravagant) but I want to see the work continue.
In terms of lib-base, -core, -back et cetera, what work do you think needs to be done? I am assuming getting the swift bridging annotation completed (nullable, method import conventions, et cetera)
I was surprised that Swift already was renaming ObjC Methods into the regular Swift format. Is swift just applying the standard rules automatically, or did you have to annotate Foundation for this? I remember the discussion in Swift 2 where I believe some of this was automatic, but I can't remember now.
Regardless, this is incredibly impressive.
What is the state of retain and release for ObjC objects and the Swift Runtime for this current release?
That's one solution. But I plan to add a SWIFT_OBJC_VENDOR macro so that we can emit symbol which matches GNUStep's ABI in the IR stage instead of Apple's one when the vendor is GNUStep.
Outside of the Swift toolchain, do you know if the ObjC symbols can be accessed? Or are there any API outside of the toolchain that expect that format? I think your solution is the correct one.
