Skip to content

[cmake] add Synchronization library to Supplemental build #81310

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

Merged
merged 1 commit into from
May 16, 2025

Conversation

justice-adams-apple
Copy link
Contributor

@justice-adams-apple justice-adams-apple commented May 5, 2025

Addresses rdar://150300769

Add Synchronization library to new build system

Land #81215 first

Comment on lines 2 to 5

set(CMAKE_POSITION_INDEPENDENT_CODE YES)

list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/../cmake/modules")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can come after the project call.

Comment on lines +19 to +14
if(NOT PROJECT_IS_TOP_LEVEL)
message(SEND_ERROR "Swift Synchronization must build as a standalone project")
endif()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should likely hoist this to right after the project call

Comment on lines 45 to 55
option(${PROJECT_NAME}_ARCH_SUBDIR "Architecture used for setting the architecture subdirectory"
${SwiftCore_ARCH_SUBDIR})

option(${PROJECT_NAME}_INSTALL_NESTED_SUBDIR "Install libraries under a platform and architecture subdirectory"
${SwiftCore_INSTALL_NESTED_SUBDIR})

option(${PROJECT_NAME}_PLATFORM_SUBDIR "Platform name used for installed swift{doc,module,interface} files"
${SwiftCore_PLATFORM_SUBDIR})

option(${PROJECT_NAME}_COMPILER_VARIANT_TARGET "Compiler variant target to use when emiting modules"
${SwiftCore_COMPILER_VARIANT_TARGET})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@etcwilde - whats your take on these defaults? I'm kinda somewhat torn. I don't like introducing more option values, but these feel like it might make sense to separate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think inheriting the value for library evolution and prespecialization is probably fine. They're defaults so if someone really doesn't want them to match, passing the option directly, using a cmake cache, or modifying the value with ccmake later will all work. Whether or not to install into the nested subdirectory is also probably fine to default to match.

The arch and platform subdirs are computed by the compiler for the platform and they aren't boolean options, so they shouldn't be options. We don't need to inherit them, just use the value coming out of PlatformInfo. Maybe later, we could look to see if these values have all been set and avoid invoking the compiler to get this info since process launches are expensive on Windows, but I don't think it's worth worrying about now.

Lets drop the defaults for:

  • platform subdirectory
  • arch subdirectory
  • compiler variant target

Comment on lines 45 to 55
option(${PROJECT_NAME}_ARCH_SUBDIR "Architecture used for setting the architecture subdirectory"
${SwiftCore_ARCH_SUBDIR})

option(${PROJECT_NAME}_INSTALL_NESTED_SUBDIR "Install libraries under a platform and architecture subdirectory"
${SwiftCore_INSTALL_NESTED_SUBDIR})

option(${PROJECT_NAME}_PLATFORM_SUBDIR "Platform name used for installed swift{doc,module,interface} files"
${SwiftCore_PLATFORM_SUBDIR})

option(${PROJECT_NAME}_COMPILER_VARIANT_TARGET "Compiler variant target to use when emiting modules"
${SwiftCore_COMPILER_VARIANT_TARGET})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think inheriting the value for library evolution and prespecialization is probably fine. They're defaults so if someone really doesn't want them to match, passing the option directly, using a cmake cache, or modifying the value with ccmake later will all work. Whether or not to install into the nested subdirectory is also probably fine to default to match.

The arch and platform subdirs are computed by the compiler for the platform and they aren't boolean options, so they shouldn't be options. We don't need to inherit them, just use the value coming out of PlatformInfo. Maybe later, we could look to see if these values have all been set and avoid invoking the compiler to get this info since process launches are expensive on Windows, but I don't think it's worth worrying about now.

Lets drop the defaults for:

  • platform subdirectory
  • arch subdirectory
  • compiler variant target


set_target_properties(swiftSynchronization PROPERTIES
Swift_MODULE_NAME Synchronization
Swift_COMPILATION_MODE wholemodule)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is WMO required to build the synchronization library? It should be fine to set CMAKE_Swift_COMPILATION_MODE in a cache or as a flag. Incremental builds make iterating on the library faster.

Swift_COMPILATION_MODE wholemodule)

if(APPLE AND BUILD_SHARED_LIBS)
target_link_options(swiftSynchronization PRIVATE "SHELL:-Xlinker -headerpad_max_install_names")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an Apple-ism that isn't needed externally. We can move it into the vendor files.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that leaving this in an APPLE clause is fine. This is mostly a MachO thing (which has a similar issue on ELF). Changing the encoded values post-facto is difficult unless padding is included when linking.

@justice-adams-apple justice-adams-apple force-pushed the add-synchronization branch 2 times, most recently from ed8ed44 to c3f5f51 Compare May 13, 2025 16:24
@justice-adams-apple
Copy link
Contributor Author

@swift-ci please smoke test

@@ -22,6 +22,7 @@ endif()

set(COMMON_OPTIONS
-DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}
-DSDKROOT=${SDKROOT}
Copy link
Contributor

@edymtt edymtt May 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we want to pass Swift_SDKROOT to be used by find_package(SwiftCore...) -- SDKROOT is meant to be an environment variable, and that should be passed as a result of child processes inheriting the environment of the parent.

Suggested change
-DSDKROOT=${SDKROOT}
-DSwift_SDKROOT=${Swift_SDKROOT}

@justice-adams-apple
Copy link
Contributor Author

@swift-ci please smoke test

@@ -22,6 +22,7 @@ endif()

set(COMMON_OPTIONS
-DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}
-DSwift_SDKROOT=${SDKROOT}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the name of the source variable needs to be amended

Suggested change
-DSwift_SDKROOT=${SDKROOT}
-DSwift_SDKROOT=${Swift_SDKROOT}

set(${PROJECT_NAME}_INSTALL_SWIFTMODULEDIR "${CMAKE_INSTALL_LIBDIR}/swift$<$<NOT:$<BOOL:${BUILD_SHARED_LIBS}>>:_static>$<$<BOOL:${Supplemental_INSTALL_NESTED_SUBDIR}>:/${Supplemental_PLATFORM_SUBDIR}>" CACHE STRING "")

install(TARGETS swiftSynchronization
EXPORT SwiftSupplementalTargets
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably it does not make sense to reference Supplemental here (since each library can be build standalone)

Suggested change
EXPORT SwiftSupplementalTargets
EXPORT SwiftSynchronizationTargets

${SwiftCore_ENABLE_PRESPECIALIZATION})

include(CatalystSupport)
include(EmitSwiftInterface)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We likely need to import InstallSwiftInterface to be able to call install_swift_interface

include(InstallSwiftInterface)

@justice-adams-apple
Copy link
Contributor Author

@swift-ci please smoke test

@compnerd
Copy link
Member

Turns out that I need this to enable the early-swift-driver on Windows :(

@compnerd
Copy link
Member

Playing around with this for Windows, I found a couple of issues. But in fixing that, I also re-ordered things to make it more uniform with the other builds. Would you like me to push the changes to this branch?

@justice-adams-apple
Copy link
Contributor Author

@compnerd I'll go ahead and land this and then you can open a new PR to make it a bit easier to manage

@compnerd
Copy link
Member

@justice-adams-apple that sounds like a plan to me - please merge this.

Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge this to unblock/fix the remaining issues.

@justice-adams-apple justice-adams-apple merged commit 50e3070 into main May 16, 2025
3 checks passed
@justice-adams-apple justice-adams-apple deleted the add-synchronization branch May 16, 2025 16:20
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.

4 participants