libdispatch switched to CMake

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

3 Likes

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!

+1!

For anyone listening in, if you run into any issues, you may need a clean build or a reconfigure.

Also in case anyone is not familiar with the bigger picture here, this down the line will enable us to eliminate autoconf as a dependency for building swift since libdispatch is the only part of swift now that depends on autoconf.

Michael

···

On Sep 18, 2017, at 3:28 PM, Saleem Abdulrasool <compnerd@compnerd.org> wrote:

Saleem

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

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?

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

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,

···

On Fri, Sep 22, 2017 at 2:31 PM, Jordan Rose <jordan_rose@apple.com> wrote:

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

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_rose@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-bounces@swift.org

On Fri, Sep 22, 2017 at 2:31 PM, Jordan Rose <jordan_rose@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=

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.

···

On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <groved@us.ibm.com> wrote:

--dave

[image: Inactive hide details for Saleem Abdulrasool via swift-dev
---09/22/2017 08:59:28 PM---On Fri, Sep 22, 2017 at 2:31 PM, Jordan]Saleem
Abdulrasool via swift-dev ---09/22/2017 08:59:28 PM---On Fri, Sep 22, 2017
at 2:31 PM, Jordan Rose <jordan_rose@apple.com> wrote: > Hey, Saleem. I
don't b

From: Saleem Abdulrasool via swift-dev <swift-dev@swift.org>
To: Jordan Rose <jordan_rose@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-bounces@swift.org
------------------------------

On Fri, Sep 22, 2017 at 2:31 PM, Jordan Rose <*jordan_rose@apple.com* > <jordan_rose@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* <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* <swift-dev@swift.org>
*https://lists.swift.org/mailman/listinfo/swift-dev*
         <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Fe4FicGBU_20P2yihxV-apaNSFb6BSj6AlkptSF2gMk&m=590xgA-Zd76OeR8vVa2Bdxi7IWZJV8gYTQUQ1orlCv4&s=S0bCeAScUV4dc_1As6tnAdHurqx2LMbVje6L-vWbo3U&e=&gt;

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org___________________________
____________________
swift-dev mailing list
swift-dev@swift.org
Proofpoint Targeted Attack Protection.
swift.org_mailman_listinfo_swift-2Ddev&d=DwIGaQ&c=jf_
iaSHvJObTbx-siA1ZOg&r=Fe4FicGBU_20P2yihxV-apaNSFb6BSj6AlkptSF2gMk&m=
590xgA-Zd76OeR8vVa2Bdxi7IWZJV8gYTQUQ1orlCv4&s=S0bCeAScUV4dc_
1As6tnAdHurqx2LMbVje6L-vWbo3U&e=

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

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?

Jordan

···

On Sep 24, 2017, at 19:32, Saleem Abdulrasool <compnerd@compnerd.org> wrote:

On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <groved@us.ibm.com <mailto:groved@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.

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

···

On Sep 25, 2017, at 11:28, Jordan Rose <jordan_rose@apple.com> wrote:

On Sep 24, 2017, at 19:32, Saleem Abdulrasool <compnerd@compnerd.org <mailto:compnerd@compnerd.org>> wrote:

On Sat, Sep 23, 2017 at 5:02 AM, David P Grove <groved@us.ibm.com <mailto:groved@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?

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?

···

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

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

Jordan

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org

Hello,

Getting similar issues when building swift-corelibs-foundation for Android on Ubuntu 18.04.
Am I properly understand that types was not found because sources from swift-corelibs-libdispatch/src/swift was not compiled during CMake build?

Thanks!

[40/245] CompileSwift: Foundation/Progress.swift
FAILED: ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o 
mkdir -p `dirname ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o`; mkdir -p ../../../Build/foundation/armv7a; /vagrant/Build/swift-android/swift-linux-x86_64/bin/swift -frontend -c Foundation/NSObject.swift Foundation/AffineTransform.swift
...
Foundation/JSONEncoder.swift -I/vagrant/Build/swift-android/swift-linux-x86_64/lib/swift/android -Xcc -fblocks -resource-dir /vagrant/Build/swift-android/swift-linux-x86_64/lib/swift -target armv7-none-linux-androideabi -sdk /vagrant/Install/android/armv7a/sysroot   -Ibootstrap/common/usr/include -Ibootstrap/common/usr/local/include   -Ibootstrap/armv7-none-linux-androideabi/usr/include -Ibootstrap/armv7-none-linux-androideabi/usr/local/include -O -DDEPLOYMENT_TARGET_ANDROID -DDEPLOYMENT_ENABLE_LIBDISPATCH -Xcc -DDEPLOYMENT_TARGET_ANDROID -I/vagrant/Install/android/armv7a/sysroot/usr/include -I../../../Build/foundation/armv7a/Foundation -I../../../Build/foundation/armv7a/Foundation/usr/lib/swift -I../../../Build/foundation/armv7a -DDEPLOYMENT_RUNTIME_SWIFT -I../../../Build/foundation/armv7a/Foundation//usr/lib/swift -licui18nswift -licuucswift -licudataswift -licuucswift -licudataswift  -lcurl  -lxml2 -DDEPLOYMENT_ENABLE_LIBDISPATCH -I/vagrant/Sources/swift/swift-corelibs-libdispatch -I/vagrant/Install/dispatch/armv7a/src/swift -Xcc -fblocks -swift-version 4 -module-name Foundation -module-link-name Foundation -o ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o -emit-module-path ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o.~partial.swiftmodule -emit-module-doc-path ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o.~partial.swiftdoc -emit-dependencies-path ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o.d -emit-reference-dependencies-path ../../../Build/foundation/armv7a/Foundation/Foundation/Progress.swift.o.swiftdeps -module-cache-path ../../../Build/foundation/armv7a
Foundation/URLSession/BodySource.swift:38:44: error: use of undeclared type 'DispatchData'
internal func splitData(dispatchData data: DispatchData, atPosition position: Int) -> (DispatchData,DispatchData) {
                                           ^~~~~~~~~~~~
Foundation/URLSession/BodySource.swift:38:88: error: use of undeclared type 'DispatchData'
internal func splitData(dispatchData data: DispatchData, atPosition position: Int) -> (DispatchData,DispatchData) {
                                                                                       ^~~~~~~~~~~~
Foundation/URLSession/BodySource.swift:32:43: error: use of undeclared type 'DispatchData'
internal func copyDispatchData<T>(_ data: DispatchData, infoBuffer buffer: UnsafeMutableBufferPointer<T>) {
                                          ^~~~~~~~~~~~
Foundation/URLSession/BodySource.swift:24:51: error: use of undeclared type 'DispatchData'
internal func createDispatchData(_ data: Data) -> DispatchData {
                                                  ^~~~~~~~~~~~
Foundation/Progress.swift:282:17: error: use of unresolved identifier 'DispatchQueue'
                DispatchQueue.global().async {
                ^~~~~~~~~~~~~

Vlad — please do not resurrect old threads for support requests.