[DNM][WIP] Implement Windows toolchain #419
Conversation
stevapple
force-pushed
the
windows-toolchain
branch
from
59019ff to
1168dea
Compare
stevapple
force-pushed
the
windows-toolchain
branch
from
1168dea to
b1e5ef9
Compare
stevapple
force-pushed
the
windows-toolchain
branch
from
74875d8 to
e270919
Compare
stevapple
changed the title
There was a problem hiding this comment.
Thanks for continuing to work on this, it's really great to hear that everything is compiling and working on Windows! I added a few initial comments and questions, but feel free to ignore anything that doesn't make sense because I'm still not very familiar with the platform. I do think that in addition to these changes, we might need to add something equivalent to addRuntimeLibraryFlags in Toolchains.cpp from the old driver, possibly in an implementation of WindowsToolchain.addPlatformSpecificCommonFrontendOptions
| if (triple.isWindows) { | ||
| result.append(sdkPath.appending(components: "usr", "lib", "swift", "windows")) | ||
| } else { |
There was a problem hiding this comment.
Is this used to find the correct path to the runtime, or something else maybe? I know in a few other places we append targetTriple.platformName() only when needed which might help remove the workaround here
There was a problem hiding this comment.
I referred to the current layout of Windows toolchain and SDK, which is slightly different from other platforms. I think we need to unify SDK layout for the convenience of cross-compilation (and to eliminate differences across platforms), how do you think @compnerd ?
| // The default linker `LINK.exe` can use `/LTCG:INCREMENTAL` to enable LTO, | ||
| // and LLVM LTOs are available through `lld-link`. Both LTO methods still need | ||
| // additional work to be integrated, so disable this option for now. | ||
| if parsedOptions.hasArgument(.lto) { |
There was a problem hiding this comment.
I think lld LTO is supported on windows now on main, but that can be addressed in a future PR
There was a problem hiding this comment.
I tried but there’re some tricky problems... In fact I got the same output with the old driver on main when I passed -use-ld=lld-link, but just doesn’t function properly.
If that’s only a rare case, I think enabling it is a easy task👌
|
Opening swiftlang/swift-tools-support-core#191 to solve some TSC bugs on Windows. Some tests will function correctly after that patch. |
|
@stevapple really awesome to see this coming along! Could you please re-base this PR so that it is a bit easier to look at the specific changes? |
|
CC @artemcm |
stevapple
force-pushed
the
windows-toolchain
branch
from
f607c8c to
d48e3e1
Compare
|
For someone who may be watching the progress: This PR needs to wait for swiftlang/swift-tools-support-core#219 which brings lots of stability in path parsing and some useful helpers for unit testing. |
|
@stevapple this is now quite stale with respect to a lot of recent work in this area by @compnerd. |
Hello everyone, I'm back!
Sorry for absence for the past months. Now,
WindowsToolchainhas been:The following commands are currently supported and tested:
swiftcswiftswift-build,swift-run,swift-testand any new ones to come)swift-repl)make-optionsSome other things to do:
swift-buildpipeline;Fix building(SR-14259);swift-driverwith SwiftPM on WindowscommandLineFitsWithinSystemLimitsandtokenizeResponseFilefor Windows.Hopefully landing by Swift 5.5 :)