-
Notifications
You must be signed in to change notification settings - Fork 125
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
build: allow building in Debug mode on Windows #445
Conversation
@swift-ci please test |
@swift-ci please test |
@swift-ci please test Windows platform |
|
||
set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreadedDLL) |
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.
Why is this MultiThreadedDLL
and not MultiThreaded$<$<CONFIG:Debug>:Debug>DLL
(in which case we can let it be the default)?
Don't we want it to expand to the library that matches, or are we not using the debug DLL in either case?
Same for the above.
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.
That is the entire point here :) We do not want to match the default because there is no debug Swift runtime with a debug MSVCRT. If we were to do that, we would need ~16 builds of the runtime to distribute:
{static,dynamic (Swift)}x{debug,release (Swift)}x{debug,release (C)}x{static,dynamic (C)}
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, so just tying the C portions to release builds so it's just a {static,dynamic}{debug,release}Swift x release{static,dynamic}C/C++ runtime bits. okay.
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.
Do we need to mix the release and debug Swift with release and debug C/C++? Wouldn't it make more sense to have everything be debug or everything be release? And would it make sense to limit the debug builds to either just dll's/static-linked? Then we only need to build the debug half for both either statically or dynamically and it's no longer a combinatorial explosion. Then the debug build is only one configuration and each thing gets built three times.
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 think that if we want to reduce it further we should continue to not support static linking. We could do dynamic only with debug and release mode and match Swift and C/C++.
With this tweak, we should be able to build the package in debug mode even on Windows. We always use the release mode DLL form of the C/C++ runtime on Windows and can build the Swift code in Debug or Release mode optimizations.
@swift-ci please test |
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.
Thank you for the comment. LGTM.
With this tweak, we should be able to build the package in debug mode
even on Windows. We always use the release mode DLL form of the C/C++
runtime on Windows and can build the Swift code in Debug or Release mode
optimizations.