Skip to content

build: allow building in Debug mode on Windows #445

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Dec 7, 2023
Merged

build: allow building in Debug mode on Windows #445

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,21 @@

if(POLICY CMP0091)
cmake_policy(SET CMP0091 NEW)
endif()

cmake_minimum_required(VERSION 3.19)

project(SwiftTSC LANGUAGES C Swift)

set(CMAKE_Swift_LANGUAGE_VERSION 5)
set(CMAKE_Swift_MODULE_DIRECTORY ${CMAKE_BINARY_DIR}/swift)
# TODO: lift this restriction once we have a split Swift runtime build which can
# be built with a debug C runtime.
set(CMAKE_Swift_COMPILE_OPTIONS_MSVC_RUNTIME_LIBRARY MultiThreadedDLL)

# TODO: lift this restriction once we have a split Swift runtime build which can
# be built with a debug C runtime.
set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreadedDLL)
Copy link
Contributor

@etcwilde etcwilde Dec 5, 2023 •
edited
Loading

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++.

set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
Expand Down