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. 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. - Brian Gesiak
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
