WiX: create and distribute SxS and flat style MSMs for developers#533
WiX: create and distribute SxS and flat style MSMs for developers#533compnerd wants to merge 5 commits into
Conversation
compnerd
force-pushed
the
msm
branch
2 times, most recently
from
2ce73a2 to
76b37b3
Compare
|
UI changes: |
compnerd
force-pushed
the
msm
branch
3 times, most recently
from
6ebb8d7 to
7f815d0
Compare
The shared runtime merge-module fragment only needs the selected RuntimeRoot. SDKRoot is supplied by the platform projects for SDK packaging and is not referenced in this fragment. Split this cleanup out before the runtime MSM changes so later commits only describe packaging behavior.
Replace the hand-maintained SDK and runtime library properties with Module and Library item declarations. Derive SDK Swift module names, shared-linkage and static-linkage SDK component groups, developer tools shared-linkage groups, runtime redistributable libraries, and static runtime dependencies from that metadata. Use the final projection rules from the start. Shared and Static are positive library availability flags, SDKSharedLinkage admits special static-only items into the shared-linkage SDK slice, SDK and runtime platforms are selected once, and static SDK component ids use the generated lib-prefixed shape. Model the special SDK cases directly: Cxx and CxxStdlib include static libraries in the shared-linkage SDK, while _FoundationCollections ships shared-linkage swiftmodule and swiftdoc files without a library. This keeps each library named once while allowing the Windows and Android packages, shared runtime library fragment, and static runtime merge module to consume the same definitions. Import the metadata only for WiX projects so native projects do not consume the Library items.
Make flat redistributable filenames carry the SxS layout segment for both linkage families: rtl.shared.unbound.<arch>.msm and rtl.static.unbound.<arch>.msm. This makes each MSM name a consistent tuple of linkage, SxS layout, and architecture before adding the bound variants.
Build bound variants for both shared and static runtime merge modules, so redistributables cover the full linkage x SxS layout x architecture matrix. The bound layout places each DLL in a basename directory for private SxS binding, while the unbound layout keeps the existing flat runtime directory. Separate module GUIDs and intermediate paths keep the variants distinct.
Expose the redistributable merge modules as layout-level bundle options instead of one per linkage/layout combination. The BA tree now shows SxS for bound MSMs and flat for unbound MSMs under each Windows SDK architecture. Default SxS to selected and flat to unselected, and forward each layout choice to both shared and static MSM components in the Windows platform MSI.
etcwilde
left a comment
etcwilde
left a comment
There was a problem hiding this comment.
You say "bound" and "unbound" and "flat" vs "SxS" a lot. The changes themselves look fine, but I don't know the definitions of these terms. Can you please include definitions of "bound" vs "unbound" in the readme. You do refer to the Side-by-Side strategy elsewhere in the readme, but I don't see anything tying SxS to the term "Swift-by-Side". The section describing what a Side-by-Side install is should at least contain a single SxS in it, ideally something like, "Side-by-Side (SxS) installs allow you to blah blah blah".
Please include a definition of "bound" and "unbound" in the context of a redistributable runtime.
Where should we add that explanation? Neither of these are really terms of art; I believe that the Microsoft naming is "shared assembly (WinSxS)" and "private assembly (app-local)" for the two models. https://devblogs.microsoft.com/cppblog/how-to-redistribute-the-visual-c-libraries-with-your-application/ is the closest thing to a reference I can find. |
|
@compnerd and I talked about this offline. The issue is that we're already using "shared" vs "static" for the library type and "shared.shared" for a shared shared-assembly library is not meaningful. Instead of "shared" library, we'll use "dynamic" vs "static" and "shared" vs "private" to align with the existing terms. |
2 participants
This pull request introduces significant improvements to how Windows and Android platform build configurations manage and reference runtime libraries, SDK modules, and installer options. The changes centralize and standardize the definition of module and component group lists, streamline variable naming, and add support for distinguishing between "bound" and "unbound" redistributable runtime libraries in the Windows installer.
Key changes include:
Centralization and Standardization of Module/Component Lists
RuntimeLibraries.propsfile that defines all Swift, Foundation, Dispatch, and overlay modules, as well as their grouping for both Windows and Android platforms. This centralizes and standardizes the way these lists are maintained and referenced. (platforms/Windows/RuntimeLibraries.props)Directory.Build.propsto import the newRuntimeLibraries.propsand to use its properties for defining build variables, ensuring consistency across the build system. (platforms/Windows/Directory.Build.props) [1] [2]Windows Installer Improvements
platforms/Windows/bundle/installer.wxs,platforms/Windows/bundle/baf/baf.cc) [1] [2] [3] [4]MergeModuleStyleandRuntimeLibraryLayoutproperties based on project and build conditions, supporting the new bound/unbound model. (platforms/Windows/Directory.Build.props)Android Build and Installer Updates
RuntimeLibraries.props, replacing hardcoded lists and simplifying maintenance. (platforms/Windows/platforms/android/android.wixproj,platforms/Windows/platforms/android/android.wxs) [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]These changes make the build and installer configuration more maintainable, flexible, and consistent across platforms, and set the stage for future enhancements to runtime library packaging and deployment.