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

[Douglas Gregor]

> 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 <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 <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 <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.

Yeah. I’d expect the main work to be in the Swift build system, the Swift driver (which decides when to pass down “-enable-objc-interop” to the frontend), and some “#ifdef __APPLE__” in the runtime that should use “#if SWIFT_OBJC_INTEROP” instead.

Swift does bake in a bit of knowledge of the Darwin Objective-C runtime, so one would likely have to tease that out of IRGen and the runtime to make mulle-objc interoperability possible. Clang has some abstractions in its CodeGen (equivalent to Swift’s IRGen) to support multiple Objective-C runtimes, and we would need something similar for Swift. That’d take a bunch of refactoring.

> So I'd like to propose that we augment the build system to allow a person compiling the Swift project to turn Objective-C interop on or off for any given target. That would allow me to compile for Linux, but with Objective-C interop enabled. Alternatively, I could compile for macOS, but with Objective-C interop disabled.
> 
> Any thoughts? I could clean up my local implementation and send a pull request, provided there's interest.

It would be great to decouple “is an Apple platform” from “provides Objective-C interoperability”!

As you noted, there are two potential use cases for this:

1) Objective-C interoperability on non-Apple platforms: I (personally) don’t find this hugely motivating, because Apple platforms have the only significant stack of existing frameworks that  Swift needs to interoperate with. Plus, there’s no single clear “winner” when it comes to picking an Objective-C runtime on non-Darwin platforms (e.g., what about GNUstep?), and (as I said above) actually supporting another Objective-C runtime is likely to require a bunch of refactoring in IRGen and runtime.
2) Swift-without-Objective-C interoperability on Apple platforms: this would be *extremely* useful for people writing cross-platform code in Swift, who want to make sure their code works the same way when using Darwin’s Foundation vs. the core libraries’ Foundation. I know that the Foundation developers would be particularly pleased with this.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161128/95dc086a/attachment.html>