[swift-dev] [RFC] Modify the build system to enable/disable ObjC interop for any platform

[John McCall]

> On Nov 28, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>> On Nov 28, 2016, at 7:26 AM, Brian Gesiak via swift-dev <swift-dev at 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.