> On Nov 28, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-dev@swift.org> > wrote: >> On Nov 28, 2016, at 7:26 AM, Brian Gesiak via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hello all! >> >> While reviewing https://github.com/apple/swift/pull/5904, I had a crazy >> thought, and I'd like to get some feedback on it. >> >> Here's my original comment >> <https://github.com/apple/swift/pull/5904#discussion_r89797900>. >> >> Basically, I notice that we have two sets of targets we compile the Swift >> runtime and standard library for: >> >> 1. 'ALL_APPLE_PLATFORMS', which is composed of macOS, iOS, tvOS, and watchOS. >> 2. The other platforms: Linux, FreeBSD, Android, Cygwin, and (as of the pull >> request above) Windows. >> >> In other words: >> >> 1. All the platforms that support Objective-C interop. I suggest we call >> these 'OBJC_INTEROP_PLATFORMS' in CMake. >> 2. All the platforms that don't. I suggest we call these >> 'NO_OBJC_INTEROP_PLATFORMS' in CMake. >> >> --- >> >> I think the above is a good idea, regardless of how you feel about my other, >> zanier thought: >> >> Over the weekend I learned of the mulle-objc project >> <https://mulle-objc.github.io>. It boasts an Objective-C compiler and >> runtime that works on Linux. >> >> Now, I don't know if Swift's Objective-C interop will work completely with >> mulle-objc, but I did a bit of experimenting over the weekend, and it seems >> possible. But one obstacle is the fact that the Swift build system conflates >> "an Apple target" with "capable of Objective-C interop." To even start >> working with mulle-objc, I had to remove a lot of `#ifdef __APPLE__` in the >> code. > > It's not only the build system, but the IRGen and runtime implementation of > ObjC interop is also heavily biased towards Apple's implementations of the > ObjC runtime and Foundation on Darwin. Just changing all those #ifdef > __APPLE__ s to #if SWIFT_OBJC_INTEROP is not going to get you very far > working with another ObjC implementation. As Doug noted, supporting ObjC-less > Darwin would on the other hand be very useful!
Right. If you really wanted to support using Swift with a different Objective-C ABIs, I think the first step would be to do some work in clang to expose an abstract API for building classes. You'd still need *some* ABI-specific code in Swift IRGen, I expect, but it ought to be possible to re-use the majority of Clang's ObjC targeting code. John. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
