Skip to content
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

Merged
merged 1 commit into from
Dec 7, 2023

Conversation

compnerd
Copy link
Member

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.

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

compnerd commented Dec 1, 2023

@swift-ci please test Windows platform

@compnerd compnerd enabled auto-merge (rebase) December 1, 2023 04:28

set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreadedDLL)
Copy link
Contributor

@etcwilde etcwilde Dec 5, 2023

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.

Copy link
Member Author

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)}

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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.
@compnerd
Copy link
Member Author

compnerd commented Dec 7, 2023

@swift-ci please test

Copy link
Contributor

@etcwilde etcwilde left a 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.

@compnerd compnerd merged commit 35afcbf into swiftlang:main Dec 7, 2023
3 checks passed
@compnerd compnerd deleted the debug branch December 7, 2023 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants