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 <
Add support for building Swift on Windows with clang-cl and MSVC by hughbe · Pull Request #5904 · apple/swift · GitHub.
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