WiX: Windows packaging improvements #207
Merged
Conversation
This file contains 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
compnerd
force-pushed
the
simplify
branch
6 times, most recently
from
f167764 to
8fb5b99
Compare
This should generate durable GUIDs at compile time to allow an in-place upgrade. Remove the unnecessary properties in the developer tools.
This restructures the MSIs into a slightly more granular set of MSIs. It reduces the size of the single MSI making the installer proceed a bit more uniformly. bld: Build Tools (binutils, compilers, linker, assembler) cli: Command Line Tools (clang-format, clang-tidy, swift-api-digester, swift-symbolgraph-extract, swift-package-manager) dbg: Debugging Tools (lldb, repl) ide: IDE Integration Tools (clangd, lldb-vscode, sourcekitd, SourceKit-LSP) In the future, this also provides a logical location for DocC (cli), swift-inspect (dbg), and swift-format (cli). Take the opportunity to use the higher compression by default on all the MSIs. This also removes `swift-build-tool` and `swift-build-sdk-interfaces` until we have a need for them. Simultaneously, we are taking advantage of the WiX 4.0 feature to create a dual-purpose MSI. Unfortunately, burn does not support dual-purpose builds and this implicitly migrates the toolchain to a per-user install currently. However, this is desirable as it will likely provide a space free install path along with removing the need for administrator rights.
compnerd
added a commit
to compnerd/apple-swift
that referenced
this pull request
Jun 9, 2023
This corresponds to swiftlang/swift-installer-scripts#207 which restructures the MSIs and enables a number of new features. It switches us to: - durable GUIDs which will enable upgrades - enables dual-purpose MSIs - switches the installer to per-user installs - should drop the requirement on Administrator rights - splits the MSIs into smaller chunks to provide a nicer installer experience - reduces the complexity in the management of the manifest
compnerd
added a commit
to compnerd/apple-swift
that referenced
this pull request
Jun 9, 2023
This corresponds to swiftlang/swift-installer-scripts#207 which restructures the MSIs and enables a number of new features. It switches us to: - durable GUIDs which will enable upgrades - enables dual-purpose MSIs - switches the installer to per-user installs - should drop the requirement on Administrator rights - splits the MSIs into smaller chunks to provide a nicer installer experience - reduces the complexity in the management of the manifest
compnerd
changed the title
compnerd
force-pushed
the
simplify
branch
2 times, most recently
from
aad7743 to
87d72d7
Compare
etcwilde
reviewed
Jun 14, 2023
There was a problem hiding this comment.
Overall, mostly sensible given what was discussed in https://forums.swift.org/t/improving-the-distribution-of-swift-on-windows/65358. Posted a few questions about where things are going.
The headers in the toolchain stand out as oddities and the XCTest dll in the SDK looks odd too. The SDK paths are also quite long. Will Windows run out of space with the limited path lengths?
Anyway, that's enough XML for me for a while.
| <File Id="libIndexStore.lib" Source="$(var.TOOLCHAIN_ROOT)\usr\lib\libIndexStore.lib" Checksum="yes" KeyPath="yes" /> | ||
| </Component> | ||
|
|
||
| <Component Directory="_usr_include_indexstore" Id="indexstore.h"> |
There was a problem hiding this comment.
Same as above, do folks need to build against the install indexstore.h
There was a problem hiding this comment.
Yes, this is used by IndexStoreDB which is part of LSP. This allows development against a toolchain for LSP without building the full compiler.
There was a problem hiding this comment.
Still seems odd. Maybe as a cli-devel/cli-dev package? Then you could package with debug symbols and such too, which might be useful for cli developers.
There was a problem hiding this comment.
I don't think that we want to package the debug symbols ever:
- it would make the installer download ~10-20G rather than ~400M (which is already large)
- it is not a common practice on Windows
- we really want to use a symbol server to auto-match the PDB for the binary
I can split this up into two MSIs, but then I think that we go down the slipper slope of what is the right place to break up the MSIs (i.e. perhaps BlocksRuntime and dispatch should be separate MSIs as well).
This makes it fit more naturally into the layout with the co-located installation. Take the opportunity to claw back some storage by enabling compression. This effectively neurtalises the effects of the split MSIs (and slightly wins even).
Restore the components, move the install location, and enable the dual-purpose installer, and enable higher compression. The higher compression helps offset some of the associated costs for the split MSIs. The SDKs are now relocated to `%ProgramFiles%\Swift\Platforms` to co-locate the Platform SDKs with the toolchain and runtime. The conversion to a dual purpose MSI will relocate this to `%LocalAppData%\Programs\Swift\Platforms`. In most cases this should be a space free path which allows us to finally migrate away from `C:\Library` and fix the issue of incorrect permissions on directories.
This was removed from use in SPM in 5.7. Update the installer to no longer add this environment variable.
compnerd
force-pushed
the
simplify
branch
2 times, most recently
from
4213252 to
e9e800d
Compare
Ensure that we properly handle the environment when installing. When performing a per-user install, we should modify the user's environment variables and when performing a per-machine install, modify the system environment variables.
Remove the use of empty nodes and collapse them to the short form. This reduces the height of the directory hierarchy listing and makes it easier to identify the leaf nodes in the file system.
The original version information has been removed from the include file and now only has the configuration for the build. This allows us to use a single definition for the various architectures.
The SDK layout is now the most complex part of the Swift distribution. Draw a rendering of the layout to make it easier to follow.
The uninstallation path is adversely effected by the dual-purpose builds. This allows installation and uninstallation to function. While this still requires the UAC prompt, a working installation is more important. A subsequent change to enable per-user installs is still feasible.
|
Verified that |
etcwilde
approved these changes
Jun 15, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This set of changes has a breath of changes:
%ProgramFiles%\Swift(Toolchains,Runtimes,Platforms)%SystemDrive%as the install rootFixes: #134 #199