<html><body><p>Hi again. Sorry for my silence on this blocks/libdispatch conversation for over a week. <br><br>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.<br><br>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?<br><br>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...<br><br>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?<br><br>thanks,<br><br>--dave<br><br>[1] <a href="https://github.com/apple/swift/pull/974">https://github.com/apple/swift/pull/974</a><br>[2] <a href="https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/swift-overlay">https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/swift-overlay</a><br><BR>
</body></html>