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

David P Grove groved at us.ibm.com
Tue Feb 2 17:05:52 CST 2016

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?

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

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?



[1] https://github.com/apple/swift/pull/974
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160202/3909f3c6/attachment.html>

More information about the swift-corelibs-dev mailing list