-
Notifications
You must be signed in to change notification settings - Fork 43
Per user bundle and side-by-side upgrade support #224
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
Conversation
- Remove per-machine resources, use per-user directories, and set packages to per-user.
- Web bundle that downloads on demand - Offline bundle with everything embedded - Custom UI with feature selection - Side-by-side upgrade strategy
...to resolve multiproc build failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this is all looking super good!
- Use `rtl` consistently. - Use `InstallRoot`/`INSTALLROOT` consistently. - Make `HelloMergeModule` build outside the source tree. - Add Windows Sandbox test scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the rtlmsi.wixproj and rtlmsi.wxs files were accidentally left off.
I blame lack of coffee. I swear they weren't showing up earlier. |
This is the build rules update to match swiftlang/swift-installer-scripts#224.
Hmm, seems that something is wrong:
Seems that we are stripping the location prefix when building the installer? |
Oh, it re-builds the MSIs? |
It should be passing the same MSBuild properties to the project references, so TOOLCHAIN_ROOT gets passed in from the original MSBuild invocation and flows down into the .wixprojs to get set as a preprocessor variable. Is it possible to get MSBuild binlogs as an artifact? |
Can you point to the CI run? |
build-windows-toolchain.bat needs some changes: barnson/swift@2f81b90. I can send that as a PR if that's easier. |
@barnson That'd be useful! |
I already have swiftlang/swift#67961 up, I can likely just roll it into it |
This is the build rules update to match swiftlang/swift-installer-scripts#224.
I'm not sure what the syntax is but |
This is the build rules update to match swiftlang/swift-installer-scripts#224.
This renames the bundle to the "Swift Tool Kit" (Software Development Kit is the expansion of SDK and results in the Swift SDK SDK). Additionally, rename the extra utilities (`plutil`) which is optional.
- Remove per-machine resources, use per-user directories, and set packages to per-user.
- Web bundle that downloads on demand - Offline bundle with everything embedded - Custom UI with feature selection - Side-by-side upgrade strategy
...to resolve multiproc build failure.
- Use `rtl` consistently. - Use `InstallRoot`/`INSTALLROOT` consistently. - Make `HelloMergeModule` build outside the source tree. - Add Windows Sandbox test scripts.
- Consolidate .wxl files to avoid duplication. - Use `online` bundle flavoring -v- `web`.
- Rename versioned directories to clarify they're versioned. - Handle multiproc build of shared .wixlib for x86 SDK packages. - Clean up empty versioned directories.
Awesome: https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/761/console ... seems that we can build that. Need to tweak the CI rules before we could merge this. |
Running https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/762/ with a workaround to see if we can get this through. |
No description provided.