v141_xp toolkit. again. and again. and...
Rethink how the Windows XP toolkit installs because the Chocolatey installer(s) changed and broke the SIMH CI/CD build. Revert to a previous strategy that updates the GH Windows runner image in-place with Microsoft's vswhere and vs_installer tools. There's some Grey Magic in how this is done, with some adapted PowerShell code from the Chocolately PS scripts. The upshot is that vs_installer spawns a subprocess to do the actual install, but there's now way to get vs_installer to actually wait for that subprocess to complete. So, the script has to look for the installer subprocesses and poll-wait for them to finish.
This commit is contained in:
B. Scott Michel
Paul Koning
parent
b982fc9997
commit
d06160871f
1 changed files with 86 additions and 29 deletions
111
.github/workflows/cmake-builds.yml
vendored
111
.github/workflows/cmake-builds.yml
vendored
|
|
@ -108,46 +108,103 @@ jobs:
|
|||
runs-on: windows-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
##+
|
||||
## NOTE: This will have to change when Github updates the windows-latest
|
||||
## image AND when Microsoft bumps the Visual Studio year.
|
||||
##
|
||||
## Things that need updating:
|
||||
## - Product ID (maybe: MS seems to be very consistent with the component
|
||||
## name, hasn't changed since VS 2019.)
|
||||
## - Channel ID
|
||||
##-
|
||||
- name: Install v141_xp (XP toolkit)
|
||||
- name: Install v141_xp (XP toolkit) and build SIMH
|
||||
shell: pwsh
|
||||
run: |
|
||||
$ErrorActionPreference = "Stop"
|
||||
$WarningPreference = "Continue"
|
||||
$packageParams = @( "--productId", "Microsoft.VisualStudio.Product.Enterprise",
|
||||
"--channelId", "VisualStudio.17.Release",
|
||||
"--add", "Microsoft.VisualStudio.Component.VC.v141.x86.x64",
|
||||
"--add", "Microsoft.VisualStudio.Component.WinXP",
|
||||
"--no-includeRecommended",
|
||||
"--includeOptional",
|
||||
"--quiet",
|
||||
"--locale en-US" ) -join " "
|
||||
choco install visualstudio2022-workload-nativedesktop --package-parameters $packageParams
|
||||
$DebugPreference = "Continue"
|
||||
|
||||
- name: vs2022-xp build
|
||||
shell: pwsh
|
||||
run: |
|
||||
$ErrorActionPreference="Stop"
|
||||
$WarningPreference="Continue"
|
||||
$env:ChocolateyInstall = Convert-Path "$((Get-Command choco).Path)\..\.."
|
||||
Import-Module "$env:ChocolateyInstall\helpers\chocolateyProfile.psm1"
|
||||
Update-SessionEnvironment
|
||||
# Fix PATH so that "C:\Strawberry" (Strawberry Perl) doesn't mess with the build
|
||||
# CMake WILL find incompatible libraries within Strawberry.
|
||||
$fixPATH = (${env:PATH}.Split(';') | `
|
||||
Where-Object { $_ -notlike "*\Strawberry\*" -and $_ -notlike "*/Strawberry/*" }) -join ';'
|
||||
$env:Path = $fixPATH
|
||||
|
||||
#+
|
||||
# Update the existing Github Visual Studio installation in-place. `vswhere` may find multiple
|
||||
# VS installations, so iterate through them all.
|
||||
#
|
||||
# This is Grey Magic. `vs_installer` exits almost immediately if you run it from the command
|
||||
# line. However, `vs_installer`'s subprocesses are well known and we look for them and wait
|
||||
# for them to terminate.
|
||||
#
|
||||
# GH Actions does something strange with stdout and stderr, so you won't get any
|
||||
# indication of failure or output that shows you that something is happening.
|
||||
#
|
||||
# The waiting code was adapted from the Chocolatey VS installer scripts.
|
||||
#-
|
||||
$vswhere = "${env:ProgramFiles} (x86)\Microsoft Visual Studio\Installer\vswhere"
|
||||
$vsinstaller = "${env:ProgramFiles} (x86)\Microsoft Visual Studio\Installer\vs_installer.exe"
|
||||
$vsInstallOut = "$env:TEMP\vsinstall-out.txt"
|
||||
$vsInstallErr = "$env:TEMP\vsinstall-err.txt"
|
||||
|
||||
& ${vswhere} -property installationPath | `
|
||||
Foreach-Object -process {
|
||||
Write-Debug ("Executing: " + $vsinstaller + " " + ($Params -join " "))
|
||||
& $vsInstaller modify --installPath "$_" --add Microsoft.VisualStudio.Component.VC.v141.x86.x64 `
|
||||
--add Microsoft.VisualStudio.Component.WinXP --quiet `
|
||||
2> $vsInstallErr | Write-Output
|
||||
|
||||
Write-Debug ('Looking for running VS installer processes')
|
||||
$vsinstallerProcesses = @('vs_installershell', 'vs_installerservice')
|
||||
do
|
||||
{
|
||||
$vsInstallerRemaining = Get-Process -Name $vsinstallerProcesses -ErrorAction SilentlyContinue | Where-Object { $null -ne $_ -and -not $_.HasExited }
|
||||
$vsInstallerProcessCount = ($vsInstallerRemaining | Measure-Object).Count
|
||||
if ($vsInstallerProcessCount -gt 0)
|
||||
{
|
||||
try
|
||||
{
|
||||
Write-Debug "Found $vsInstallerProcessCount still running Visual Studio installer processes which are known to exit asynchronously:"
|
||||
$vsInstallerRemaining | Sort-Object -Property Name, Id | ForEach-Object { '[{0}] {1}' -f $_.Id, $_.Name } | Write-Debug
|
||||
Write-Debug ('Giving the processes some time to exit')
|
||||
$vsInstallerRemaining | Wait-Process -Timeout 1 -ErrorAction SilentlyContinue
|
||||
Write-Debug ('Looking for running VS installer processes')
|
||||
}
|
||||
finally
|
||||
{
|
||||
$vsInstallerRemaining | ForEach-Object { $_.Dispose() }
|
||||
$vsInstallerRemaining = $null
|
||||
}
|
||||
}
|
||||
}
|
||||
while ($vsInstallerProcessCount -gt 0)
|
||||
}
|
||||
|
||||
if ((Test-Path $vsInstallOut -PathType Leaf) -and (Get-Item $vsInstallOut).length -gt 0kb)
|
||||
{
|
||||
Write-Output "-- vsinstaller output:"
|
||||
Get-Content $vsInstallOut
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Debug "-- No vsinstaller output."
|
||||
}
|
||||
|
||||
if ((Test-Path $vsInstallErr -PathType Leaf) -and (Get-Item $vsInstallErr).length -gt 0kb)
|
||||
{
|
||||
Write-Output "-- vsinstaller error output:"
|
||||
Get-Content $vsInstallErr
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Debug "-- No vsinstaller error/diag output."
|
||||
}
|
||||
|
||||
#+
|
||||
# The GH Windows runner image documentation says that the VSSetup module is installed, from
|
||||
# whence Get-VSSetupInstance and Select-VSSetupInstance are imported. This step is pure
|
||||
# paranoia, ensuring that we really, truly and honestly have WinXP support.
|
||||
#-
|
||||
Write-Debug "Get-VSSetupInstance/Select-VSSetupInstance"
|
||||
Get-VSSetupInstance -All | Select-VSSetupInstance -Require 'Microsoft.VisualStudio.Component.WinXP' -Latest
|
||||
|
||||
## Don't use LTO for XP. XP compatibility comes from VS2017 -- MS is
|
||||
## at VS2022. There are likely legacy bugs that have been fixed.
|
||||
./cmake/cmake-builder.ps1 -flavor vs2022-xp -config Release -clean -verbose -notest -cpack_suffix win32-xp
|
||||
|
||||
|
||||
- name: SIMH simulator suite test
|
||||
shell: pwsh
|
||||
run: |
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue