> On Sep 25, 2017, at 11:28, Jordan Rose <jordan_r...@apple.com> wrote: > > > >> On Sep 24, 2017, at 19:32, Saleem Abdulrasool <compn...@compnerd.org >> <mailto:compn...@compnerd.org>> wrote: >> >> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <gro...@us.ibm.com >> <mailto:gro...@us.ibm.com>> wrote: >> 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? >> >> >> Yeah, that double configuration should not be needed. I'll make that >> dependency more explicit and clean up some of the usage in the SourceKit >> case. But, there is no reason to do two different builds here. The only >> bits needed to build dispatch AFAICT, is the swift core library and the >> swift compiler. Even if the swift overlay is required, we can add that >> build ordering. The dispatch overlay is constructed in libdispatch itself. >> So, we can just order the compiler build to occur prior to the libdispatch >> build, which needs to be built before SourceKit. >> >> Thanks for making me take a second look and notice that the explicit >> dependency is missing. >> > > Thanks for looking into this, but I feel like the problem has to be something > simpler. A completely clean build does this: > > libdispatch: using gold linker > + /usr/bin/cmake --build > /home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 > -- -j24 all > [1/1] cd > /home/jrose/public/build/Ninj...s-libdispatch/private/module.modulemap > foundation: using gold linker > + pushd /home/jrose/public/swift-corelibs-foundation > ~/public/swift-corelibs-foundation ~/public/swift > + env > SWIFTC=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc > > CLANG=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/llvm-linux-x86_64/bin/clang > > SWIFT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swift > > SDKROOT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64 > > BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/foundation-linux-x86_64 > DSTROOT=/ PREFIX=/usr/ ./configure RelWithDebInfo > -DXCTEST_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/xctest-linux-x86_64 > -DLIBDISPATCH_SOURCE_DIR=/home/jrose/public/swift-corelibs-libdispatch > -DLIBDISPATCH_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 > > i.e. Dispatch isn't being built at all. This is on an Ubuntu 16.04 system > with CMake 3.5.1. My build-script invocation isn't particularly complicated > either, and doesn't seem different in any interesting way from what the > buildbot is doing: > > utils/build-script -r -t --build-swift-static-stdlib > --build-swift-dynamic-stdlib --libdispatch --foundation --xctest > --skip-test-swift > > Any ideas?
Aha, passing --reconfigure seems to have made a difference. That implies to me that something is incorrectly detecting when CMake generation needs to happen. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
