On Mon, Sep 25, 2017 at 11:39 AM, Jordan Rose <jordan_r...@apple.com> wrote:
> > > 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> > wrote: > > On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <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. > Interesting. Could it be something silly in `build-script-impl` perhaps? That is a pretty scary script. A quick `set -x` `set +x` around the configure logic should help see whats going on for the libdispatch build. I wonder if there is something with ordering? > Jordan > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
