Skip to content

Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

owenv
Copy link

@owenv owenv commented Apr 29, 2025

This is my first time touching the windows installer, so there may be some silly mistakes here. Opening the PR now so I can run some tests

@owenv owenv force-pushed the owenv/add-swiftbuild-libs branch from e4d3a59 to ab10d2d Compare April 29, 2025 16:46
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.

This change is technically correct and nothing to be done here.

However, because no good deed goes unpunished - looking at this entry makes me wonder if we are building Swift Build properly. Should all these dynamic libraries be dynamic? Would we do better in terms of size and performance to convert some of them to static? I do not have the answer to that, and that is something that requires experimentation. That is something that we should really consider and evaluate (and make the appropriate changes here).

That work however IMO should be a follow up change. Packaging and distributing SwiftBuild as a starting point is the right thing to do.

One final question: should this also go into 6.2?

@owenv
Copy link
Author

owenv commented Apr 29, 2025

Right now building all the libraries as dynamic simplifies the build by making it easy to ensure we're picking the right linker driver to pull in the c++ stdlib + blocks runtime in the right targets. With some tweaks to swift-driver and general build config cleanup, I think we can gain a lot of flexibility here and experiment with alternate layouts. That said, we've been shipping the fully dynamically linked version on macOS for quite awhile without issues, so I'm not too concerned about perf impact.

One final question: should this also go into 6.2?

I intend to cherrypick to 6.2 but I'd like to make sure this + the SwiftPM changes are working end-to-end on main first

@compnerd
Copy link
Member

Please do a cross-repo test with building the toolchain for Windows and Windows ARM64 before merging.

@owenv
Copy link
Author

owenv commented Apr 29, 2025

hmm seeing failures in the cross-repo toolchain build

         C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64\swift-installer-scripts\platforms\Windows\cli\cli.wxs(239): error WIX0150: Undefined preprocessor variable '$(TOOLCHAIN_ROOT)'. [C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64\swift-installer-scripts\platforms\Windows\cli\cli.wixproj]

Which is true, TOOLCHAIN_ROOT isn't on the command line:

  C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\AMD64\MSBuild.exe -noLogo -maxCpuCount -restore C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows\swift-installer-scripts\platforms\Windows\bundle\installer.wixproj -p:WORKAROUND_MIMALLOC_ISSUE_997=False -p:Configuration=Release -p:AndroidArchitectures="" -p:WindowsRuntimeX64=T:\\Program Files\\Swift\\Runtimes\\0.0.0 -p:ImageRoot=T:\\Program Files\\Swift\\ -p:BaseOutputPath=T:\x86_64-unknown-windows-msvc\installer\ -p:ProductArchitecture=amd64 -p:VCRedistDir=C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Redist\\MSVC\\14.42.34433\\x64\\Microsoft.VC143.CRT\\ -p:WindowsRuntimeX86=T:\\Program Files (x86)\\Swift\\Runtimes\\0.0.0 -p:WindowsArchitectures="x86_64;i686;aarch64" -p:Platforms="windows" -p:ProductVersion=0.0.0 -p:WindowsRuntimeARM64=T:\\Program Files (Arm64)\\Swift\\Runtimes\\0.0.0 -p:SWIFT_DOCC_RENDER_ARTIFACT_ROOT=C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows\swift-docc-render-artifact -p:INCLUDE_SWIFT_DOCC=True -p:BundleFlavor=offline -p:SWIFT_DOCC_BUILD=T:\x86_64-unknown-windows-msvc\DocC\release -binaryLogger:T:\x86_64-unknown-windows-msvc\msi\amd64-installer.binlog -detailedSummary:False

@owenv owenv force-pushed the owenv/add-swiftbuild-libs branch from ab10d2d to 2ddf127 Compare April 30, 2025 15:32
@owenv
Copy link
Author

owenv commented Apr 30, 2025

Think I just needed a rebase, my local checkout was old

@owenv owenv force-pushed the owenv/add-swiftbuild-libs branch from 2ddf127 to dca65b9 Compare April 30, 2025 23:08
@owenv
Copy link
Author

owenv commented Apr 30, 2025

TOOLCHAIN_ROOT -> ToolchainRoot to align with the changes I rebased on

@owenv
Copy link
Author

owenv commented May 1, 2025

Verified that the toolchains built successfully and can be installed:
https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/5861/
https://ci-external.swift.org/job/swift-PR-build-toolchain-windows-arm64/23/

I can launch SwiftPM without any missing DLL errors, which is a good sign that nothing is broken at runtime. I couldn't test much more than that because swiftc.exe is crashing in mimalloc when compiling manifests:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
  <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" /> 
  <EventID>1000</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2025-05-01T04:17:48.5571991Z" /> 
  <EventRecordID>4839</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="7872" ThreadID="32036" /> 
  <Channel>Application</Channel> 
  <Computer>OWENVOORHEE74EB</Computer> 
  <Security UserID="S-1[-](https://github.com/swiftlang/swift-installer-scripts/pull/%5Cl%20%22%22)5-21-2521025350-2452346296-830454161-1000" /> 
  </System>
- <EventData>
  <Data Name="AppName">swift.exe</Data> 
  <Data Name="AppVersion">0.0.0.0</Data> 
  <Data Name="AppTimeStamp">6812d77b</Data> 
  <Data Name="ModuleName">mimalloc.dll</Data> 
  <Data Name="ModuleVersion">0.0.0.0</Data> 
  <Data Name="ModuleTimeStamp">6812da2b</Data> 
  <Data Name="ExceptionCode">c0000005</Data> 
  <Data Name="FaultingOffset">0000000000003000</Data> 
  <Data Name="ProcessId">0x727c</Data> 
  <Data Name="ProcessCreationTime">0x1dbba4fee0a32cf</Data> 
  <Data Name="AppPath">C:\Users\ovoorhees\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift.exe</Data> 
  <Data Name="ModulePath">C:\Users\ovoorhees\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\mimalloc.dll</Data> 
  <Data Name="IntegratorReportId">5cadc577-a629-4041-96c2-f300ca1a7d27</Data> 
  <Data Name="PackageFullName" /> 
  <Data Name="PackageRelativeAppId" /> 
  </EventData>
  </Event>

I expect this is probably unrelated to the changes here since the compiler/driver should be unaffected, but I'll see if there's anything I can double-check - any concerns on your end @compnerd?

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.

2 participants