-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Enable SwiftCompilerSources on Windows #73247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@swift-ci test windows |
CMakeLists.txt
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lldb is not built before swift, it is built alongside as a single unified build. This implies that there is a missing dependency in the LLDB build definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying. I updated the comment (We can fix the underlying problem in a follow-up PR).
SwiftCompilerSources/CMakeLists.txt
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Statically linking the standard library is not supported - how do we ensure that this is not applied to it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I thought that -static means that the currently built module is statically linked. The option is applied to the SwiftCompilerSources modules (and not to the stdlib).
Anyway, without this option it doesn't work and with this option it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay, this flag is only applied to SwiftCompilerSources? If so, that should be fine. I just wanted to ensure that it didn't accidentally leak. You are correct that it only applies to the module that you are building.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to implement this with the Win32 + ucrt APIs to convert the stderr handle to a FILE *.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this works on newer compilers, perhaps we should also include a version check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still need to check if it works with newer compilers
0fcfbbd to
6ae7846
Compare
|
@swift-ci test Windows |
6ae7846 to
b5a6f37
Compare
|
@swift-ci test Windows |
b5a6f37 to
b569328
Compare
|
@swift-ci test Windows |
b569328 to
b5ab832
Compare
|
@swift-ci test windows |
|
The build is failing with I didn't see this problem when building locally on my machine. |
b5ab832 to
8f447fb
Compare
|
@swift-ci test Windows |
8f447fb to
b5c4457
Compare
|
@swift-ci test Windows |
This is likely another missing dependency in the build graph (CC: @etcwilde). The build is shuffled on differently on different hosts. The dependencies should be accurate to avoid these types of spurious failures. |
I already fixed it. I was using some wrong build options |
It's not needed and doesn't work on Windows
…re not compilable on windows
…ling convert_function simplification
…s when building on Windows
b5c4457 to
dcf27a1
Compare
|
@swift-ci test |
With some hacks and workarounds I could get SwiftCompilerSources working on my local Windows machine.
To-do: also enable it in lldb (see my comment in the top-level CMakeLists file).