Repository navigation
Add CMake build support - #96
Closed
rksharma-owg wants to merge 7 commits into
Closed
rksharma-owg wants to merge 7 commits into
rksharma-owg wants to merge 7 commits into
Conversation
**Motivation:** Swift Service Context has no CMake build, preventing CMake-based consumers from building its libraries (apple#86). **Modifications:** Add explicit module targets, Swift package compilation settings, build-tree and relocatable install exports, and independent consumer tests with build documentation. Preserve SwiftPM and the runtime source. **Result:** CMake consumers can build, import, link, and run against static or shared libraries. Local macOS and Linux Swift 6.4 tests cover Ninja and Ninja Multi-Config and moved installation prefixes.
**Motivation:** The required license check expects the complete project header. Generic helper names can also collide in CMake superbuilds. **Modifications:** Add the required headers and scope helper names to their package. **Result:** The upstream license script passes locally, and static/shared Ninja and Ninja Multi-Config builds with build-tree and relocated consumers pass on macOS and Linux.
**Motivation:** The Windows consumer test cannot link because Swift requests lib-prefixed libraries while CMake emits unprefixed MSVC library names. **Modifications:** Use the lib prefix for Windows libraries and import libraries. Document the Visual Studio developer environment required for standalone compiler/linker invocations. **Result:** CMake output names match Swift autolink requests. The existing Windows consumer is the regression check; its cloud rerun is pending. The macOS superbuild consumer and license checks pass locally.
**Motivation:** CMake's MSVC C backend initializes shared linker flags that Swift cannot consume directly. The real Windows shared-library build fails before linking its consumer. **Modifications:** Document Clang's GNU-style C driver for Windows configuration and report unsupported shared-driver combinations early. Give the consumer the same C/Swift platform initialization as the libraries and clarify its dependency prefix example. **Result:** Windows configuration uses Swift-compatible linker conventions without dropping linker checks. Static/shared macOS consumers pass; Windows shared validation is pending.
**Motivation:** The real shared-library test shows that Swift requests ServiceContextModule.lib for DLL imports, while static imports require libServiceContextModule.lib. Applying the prefix to both forms prevents the dependent DLL from linking. **Modifications:** Apply the lib prefix only to Windows static library targets. Keep native shared-library and import-library names. **Result:** Target names match the distinct Swift autolink conventions. Static Windows consumers already passed; shared Windows validation of this correction is pending.
**Motivation:** Hosted consumer tests pass but report conflicting CRT defaults. CMake selects the debug CRT for Debug configurations while the Swift SDK uses the release DLL CRT. **Modifications:** Default Windows library and consumer targets to MultiThreadedDLL unless callers explicitly choose a runtime. Document the matching setting for independent consumers. **Result:** Debug and release configurations select the SDK-compatible CRT without suppressing linker diagnostics. The existing hosted consumer tests will validate the Windows correction; Unix configure/build checks pass.
Contributor
|
@rksharma-owg thank you for the PR! I would recommend waiting for the #92 to be merged, because it changes repo structure significantly. I also think after that we no longer need CMake support, as SDT no longer depends on it. |
Contributor
|
Most of the SSC content has been moved to the SDT and this is now a thin backward compatibility package. No need to add CMake build for it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The package cannot currently be built by a CMake consumer because it has no CMake entry point. This adds the library targets described in Package.swift, build-tree and relocatable installed package exports, and an independent consumer that imports and exercises both public modules.
The build supports Swift 6.2+ and CMake 3.29+ with Ninja; Ninja Multi-Config requires CMake 4.0+. Build instructions cover the required Windows developer environment. On Windows, InstrumentationBaggage stays static in shared builds because its re-exports/type aliases produce no DLL import library. ServiceContextModule follows BUILD_SHARED_LIBS. Runtime Swift source and Package.swift are unchanged.
Validation:
This targets current main. The pending ServiceContext move in #92 changes the dependency direction and would require adapting the CMake graph when merged.
Closes #86.