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

[Brian Gesiak]

Thanks all! It's great to hear that this wouldn't be completely unwelcome
-- especially Swift Darwin with Objective-C interop disabled.

I'll try and send a patch sometime soon -- although I'm busy with work
stuff, so at the latest it'll be sometime in December... in the meantime, I
created a task for it: https://bugs.swift.org/browse/SR-3292. Feel free to
comment there, or to claim the task for yourself. :)

- Brian Gesiak


On Mon, Nov 28, 2016 at 5:02 PM, John McCall <rjmccall at apple.com> wrote:

> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161129/1d36d2fb/attachment.html>