Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
···
On Sep 23, 2016, at 0:51, no-reply@swift.org wrote:
Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
I wonder if it would just make sense to create a cmake build system for dispatch and have ninja just understand the dependencies. If we update to a newer cmake (3.6), we can use subninja's to just have ninja understand the dependencies directly.
···
On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:
On Sep 23, 2016, at 0:51, no-reply@swift.org <mailto:no-reply@swift.org> wrote:
Alternately, we could change their build scripts to generate llbuild manifest files and build using llbuild (which tracks the Swift compiler version automatically as a dependency). This is why SwiftPM doesn't usually hit this problem, for example.
- Daniel
···
On Sep 24, 2016, at 7:57 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:
On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
I wonder if it would just make sense to create a cmake build system for dispatch and have ninja just understand the dependencies. If we update to a newer cmake (3.6), we can use subninja's to just have ninja understand the dependencies directly.
On Sep 23, 2016, at 0:51, no-reply@swift.org <mailto:no-reply@swift.org> wrote:
Alternately, we could change their build scripts to generate llbuild manifest files and build using llbuild (which tracks the Swift compiler version automatically as a dependency). This is why SwiftPM doesn't usually hit this problem, for example.
I do not understand how swiftpm could help here given that part of the issue is in the dispatch overlay. This is currently built by Swift's cmake build system. Could you be more explicit about what you are suggesting?
Michael
···
On Sep 24, 2016, at 8:15 PM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
- Daniel
On Sep 24, 2016, at 7:57 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
I wonder if it would just make sense to create a cmake build system for dispatch and have ninja just understand the dependencies. If we update to a newer cmake (3.6), we can use subninja's to just have ninja understand the dependencies directly.
On Sep 23, 2016, at 0:51, no-reply@swift.org <mailto:no-reply@swift.org> wrote:
Alternately, we could change their build scripts to generate llbuild manifest files and build using llbuild (which tracks the Swift compiler version automatically as a dependency). This is why SwiftPM doesn't usually hit this problem, for example.
I do not understand how swiftpm could help here given that part of the issue is in the dispatch overlay. This is currently built by Swift's cmake build system. Could you be more explicit about what you are suggesting?
I didn't say swiftpm, I said an llbuild manifest. The actual build system SwiftPM uses is provided by llbuild's swift-build-tool, and doesn't depend on Swift.
I haven't kept up with how libdispatch is built, I assumed it was using a custom build process like Foundation and XCTest.
- Daniel
···
On Sep 24, 2016, at 9:33 PM, Michael Gottesman <mgottesman@apple.com> wrote:
On Sep 24, 2016, at 8:15 PM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
Michael
- Daniel
On Sep 24, 2016, at 7:57 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
I wonder if it would just make sense to create a cmake build system for dispatch and have ninja just understand the dependencies. If we update to a newer cmake (3.6), we can use subninja's to just have ninja understand the dependencies directly.
On Sep 23, 2016, at 0:51, no-reply@swift.org <mailto:no-reply@swift.org> wrote:
Alternately, we could change their build scripts to generate llbuild manifest files and build using llbuild (which tracks the Swift compiler version automatically as a dependency). This is why SwiftPM doesn't usually hit this problem, for example.
I do not understand how swiftpm could help here given that part of the issue is in the dispatch overlay. This is currently built by Swift's cmake build system. Could you be more explicit about what you are suggesting?
I didn't say swiftpm, I said an llbuild manifest. The actual build system SwiftPM uses is provided by llbuild's swift-build-tool, and doesn't depend on Swift.
Sorry for me being unclear. I was saying that anything that worked with swiftpm's build would not work here given that we are talking about dependencies in between Swift's cmake build and ilbdispatch's build.
···
On Sep 24, 2016, at 10:29 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Sep 24, 2016, at 9:33 PM, Michael Gottesman <mgottesman@apple.com <mailto:mgottesman@apple.com>> wrote:
On Sep 24, 2016, at 8:15 PM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
I haven't kept up with how libdispatch is built, I assumed it was using a custom build process like Foundation and XCTest.
- Daniel
Michael
- Daniel
On Sep 24, 2016, at 7:57 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Foundation/NSData.swift:19:8: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
import Dispatch
^
I thought we fixed this—we need to build Swift, then libdispatch, then the Dispatch overlay, then Foundation. Has no one set that up yet?
I wonder if it would just make sense to create a cmake build system for dispatch and have ninja just understand the dependencies. If we update to a newer cmake (3.6), we can use subninja's to just have ninja understand the dependencies directly.
On Sep 23, 2016, at 0:51, no-reply@swift.org <mailto:no-reply@swift.org> wrote: