[swift-dev] libdispatch switched to CMake

[Jordan Rose]

> On Sep 25, 2017, at 11:28, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
> 
>> On Sep 24, 2017, at 19:32, Saleem Abdulrasool <compnerd at compnerd.org <mailto:compnerd at compnerd.org>> wrote:
>> 
>> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <groved at us.ibm.com <mailto:groved at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170925/05595f2d/attachment.html>