[swift-dev] libdispatch switched to CMake

[Saleem Abdulrasool]

On Mon, Sep 25, 2017 at 11:39 AM, Jordan Rose <jordan_rose at apple.com> wrote:

>
>
> 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>
> wrote:
>
> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170926/27e7395b/attachment.html>