[swift-corelibs-dev] libdispatch prep for integration to the rest of swift-corelibs

[Tony Parker]

Hi Dave,

Thanks for the update! It seems like you’ve really made great progress on this.

> On Feb 2, 2016, at 3:05 PM, David P Grove via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi again. Sorry for my silence on this blocks/libdispatch conversation for over a week. 
> 
> I've been experimenting with taking the Swift and Objective C code from the Dispatch overlay (swift/stdlib/public/SDK/Dispatch/) and getting it built into libdispatch using libdispatch's existing autotools-based build system. This is my understanding of the direction Tony suggested we pursue in pull request #974 [1]. I have a branch of libdispatch [2] which can produce a Dispatch.swiftmodule and libdispatch.so that can be used to satisfy an import Dispatch request from a Swift program and allow Swift blocks to be submitted to dispatch functions like dispatch_async. The resulting executable runs successfully and uses libdispatch. So perhaps this is getting close, but I had some questions.
> 
> One of the not nice things is that just like the existing overlay, it uses @convention(block) to cause the compiler to generate code that bridges between Swift blocks and the Objective C compatible blocks that dispatch is expecting/using internally. This (a) is less efficient than I would like and (b) forces the Swift program that imports Dispatch to be compiled with -Xcc -fblocks -Xlinker -lBlocksRuntime. I don't see a good way of avoiding this absent some compiler work that allow all of the C code in dispatch & its test suite to be compiled to use Swift compatible blocks. I'm assuming this would take a while, so we should try to not gate progress on integrating dispatch with this compiler work. Is this approach reasonable for now? Can we do better?
> 
> 

I think we can absolutely do better — but I’m also a believer in incremental development. If we get this started by requiring Swift apps to put in the special flags and link the runtime, then we can tackle that problem separately.

> Another not nice thing is that the libdispatch build uses libtool to get portable compilation of C/C++ code. I tried and failed to get libtool to integrate reasonable with swiftc. As a result the rules that produce Dispatch.o from Dispatch.swift so it can be linked into libdispatch.la is not going to be very portable. If someone has better ideas, that would be good…
> 
> 
Hm, not sure about this one. If we can get support for our two Ubuntu platforms though, then I think others will be happy to help jump in and help solve portability problems.

> I have a little more work to do so that the install target includes DIspatch.swiftmodule and module.map in the set of things that are installed. Is there more that needs to be done before a pull request to get this into libdisaptch makes sense?
> 
> thanks,
> 
> —dave
> 
> 
Let’s get the PR started and then make improvements from there.

Thanks again for your hard work on this! Swift on Linux will be much better with integrated support for dispatch. I can’t wait to remove some #ifdefs in Foundation.

- Tony
> [1] https://github.com/apple/swift/pull/974 <https://github.com/apple/swift/pull/974>
> [2] https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/swift-overlay <https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/swift-overlay>
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160203/f209a5ec/attachment.html>