With autotools, the first time libdispatch was built (for SourceKit), it just did the C build of libdispatch. That had to be blown away and rebuilt a second time later (once swiftc, etc was available) so that we could build libdispatch.so with the Swift overlay built into it.
Did you manage to change this so that the first time libdispatch is built it has a swiftc and Swift standard library it can use for its build? --dave From: Saleem Abdulrasool via swift-dev <swift-dev@swift.org> To: Jordan Rose <jordan_r...@apple.com> Cc: swift-dev <swift-dev@swift.org> Date: 09/22/2017 08:59 PM Subject: Re: [swift-dev] libdispatch switched to CMake Sent by: swift-dev-boun...@swift.org On Fri, Sep 22, 2017 at 2:31 PM, Jordan Rose <jordan_r...@apple.com> wrote: Hey, Saleem. I don't build libdispatch that often, but it seems to be broken for me. If I delete the libdispatch-specific build directory and then use build-script with --reconfigure, it doesn't actually attempt to reconfigure. [4/50] Performing build step for 'libdispatch' FAILED: cd /home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 && /usr/bin/cmake --build . && /usr/bin/cmake -E touch /home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/tools/SourceKit/libdispatch-prefix/src/libdispatch-stamp/libdispatch-build When I deleted my entire build directory and built from scratch, libdispatch built, but Foundation couldn't see it. Foundation/URLSession/http/HTTPURLProtocol.swift:325:19: error: use of undeclared type 'DispatchData' case data(DispatchData) ^~~~~~~~~~~~ Any ideas what's going wrong? So, definitely have an idea for the first case. When building for Linux, the libdispatch build is shared across the swift build and the libdispatch build. libdispatch is built as part of swift to be linked into SourceKit. If you disable SourceKit, this dependency will be broken. The Jenkins builds had this exact issue (which we were able to identify between myself, mgottesmann, JoeS. and mishal_shah). With the switch to CMake, the dependency should be tracked and you do not need to blow away libdispatch inbetween the builds (which is the better option -- just treat the incremental builds as incremental, no need to do any clean up). As to the Foundation issue, Im not sure ... possibly that the swift module is not built? Ill try to take a look at that (though, honestly, that would probably be tomorrow). Sorry about the trouble there (it built for me and on the build bots). Thanks, Jordan On Sep 18, 2017, at 15:28, Saleem Abdulrasool via swift-dev < swift-dev@swift.org> wrote: Hello swift-dev, This change should be transparent to everyone, but, it still is a pretty big milestone. As of this afternoon, the non-Darwin builds use CMake to build libdispatch. This work has been underway for quite some time, and we have finally switched to that as the default on most targets. This should be more or less transparent to everyone developing with build-script or even invoking CMake for swift directly. This simplifies some of the logic for integrating the projects and avoid unnecessary commands from being run. Thanks particularly to Michael Gottesman, Chris Bieneman, Daniel Steffen, David Grove, and Pierre Habouzit. Sorry if I accidentally left someone off the list! Saleem -- Saleem Abdulrasool compnerd (at) compnerd (dot) org _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev -- Saleem Abdulrasool compnerd (at) compnerd (dot) org _______________________________________________ swift-dev mailing list swift-dev@swift.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Fe4FicGBU_20P2yihxV-apaNSFb6BSj6AlkptSF2gMk&m=590xgA-Zd76OeR8vVa2Bdxi7IWZJV8gYTQUQ1orlCv4&s=S0bCeAScUV4dc_1As6tnAdHurqx2LMbVje6L-vWbo3U&e=
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev