utils: enable early swift driver on Windows #76574
Conversation
|
@swift-ci please test Windows platform |
2 similar comments
|
@swift-ci please test Windows platform |
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
4f3524d to
c44c098
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
3 times, most recently
from
0083a3c to
808146f
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
808146f to
e5800fe
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
3 times, most recently
from
54f6c65 to
f629b58
Compare
|
@swift-ci please test Windows platform |
1 similar comment
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
f629b58 to
503a318
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
503a318 to
b7acbfb
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
b7acbfb to
13ca693
Compare
|
@swift-ci please test Windows platform |
1 similar comment
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
13ca693 to
c3001fe
Compare
|
@swift-ci please test Windows platform |
1 similar comment
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
c3001fe to
9105f06
Compare
|
@swift-ci please test Windows platform |
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
utils/build.ps1
Outdated
There was a problem hiding this comment.
As far as I understand (recalling from SwiftPM work I did last year) this is Windows specific because the swift-driver that is build with the "target" compiler is going to be placed close to the executable and that's the way how windows handles dynamic libraries (they have to be either close to the binary that uses them or on the PATH), so we have to link "host" built driver to things that are going to use it, do I understand this correctly?
I was helping Artem with new driver integration into swift-ide-test and the question is whether it's worth the trouble to maintain dynamic library for earlyswiftdriver on Linux/macOS as well (and put it in lib/swift/host/swift in the toolchain) or make it a static library as well, maybe you have thoughts?
There was a problem hiding this comment.
As far as I understand (recalling from SwiftPM work I did last year) this is Windows specific because the swift-driver that is build with the "target" compiler is going to be placed close to the executable and that's the way how windows handles dynamic libraries (they have to be either close to the binary that uses them or on the PATH), so we have to link "host" built driver to things that are going to use it, do I understand this correctly?
I don't follow this. The terminology makes this challenging to follow. There are only two builds involved:
- build: the machine that the build is running on
- host: the machine that the product will run on
Given that this is a build tool, we know that build == host.
You are correct that Windows (amongst others) do not support RPATH and so you need to copy the DLLs to specific locations (i.e. in Path or the executable directory).
I was helping Artem with new driver integration into swift-ide-test and the question is whether it's worth the trouble to maintain dynamic library for earlyswiftdriver on Linux/macOS as well (and put it in lib/swift/host/swift in the toolchain) or make it a static library as well, maybe you have thoughts?
Windows definitely cannot support dynamic linking for the early swift-driver. The placement and Path adjustment interferes with the testing of the swift driver. That was the motivation for finally addressing the shortcoming (and the remainder of the issues like the ClangImporter, Foundation, build, etc).
The CMake build can do the full dependency tree build and avoids any type of copying. I would like to see lib/swift/host/swift removed and would think that especially for developer tools and build tools, static linking is preferable. We do not need to consider binary sizes there due to these tools being used only on the build machine and not being shipped. The performance implications of these tools is a separate concern, but again, I think that the increased memory pressure is worth the simplicity.
compnerd
force-pushed
the
early-driver-win
branch
from
2a8212e to
c04d663
Compare
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
2 times, most recently
from
148768d to
9b75b00
Compare
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
9b75b00 to
a69b772
Compare
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
3 times, most recently
from
215bad4 to
81d1a52
Compare
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
1 similar comment
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
81d1a52 to
d4db5b8
Compare
|
swiftlang/swift-foundation#1421 @swift-ci please build toolchain Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
d4db5b8 to
8329049
Compare
compnerd
force-pushed
the
early-driver-win
branch
from
8329049 to
37587df
Compare
|
@swift-ci please test Windows platform |
compnerd
force-pushed
the
early-driver-win
branch
from
37587df to
09e1921
Compare
|
@swift-ci please test Windows platform |
Use the experimental SDK to build the toolchain and consume the redistributable. This is going to ensure that we build the entire toolchain against a stable point and run against the runtime that we build against.
This prepares the swift-driver building on Windows. By statically linking the runtime and its dependencies, this will allow us to avoid the runtime shuffling that is required to get the runtime required to get the swift-driver working.
Enable the use of the early swift-driver to build the Swift toolchain. This is the first step towards removing the accumulated debt and workarounds when building the toolchain on Windows.
compnerd
force-pushed
the
early-driver-win
branch
from
09e1921 to
909748e
Compare
|
@swift-ci please test Windows platform |
|
@swift-ci please smoke test |
|
@swift-ci please test Windows platform |
2 participants
No description provided.