Update maOS the macos-14 runner name to macos-latest. Reduce the
runner's output when dealing with the leftover Python3 artifacts in
/usr/local.
Add the ubuntu-latest runner to the Ubuntu matrix.
- Per Github messages, upgrade checkout@v3 to checkout@v4 due to an
upgrade to Node.js.
- macos-11 is now a defunct image runner. Homebrew packages either have
to compile from source or no longer install correctly.
- Update the macos compile matrix. Set CPACK_SUFFIX environment variable
to indicate macOS hardware platform: macos-14 is M1, whereas macos-12
and macos-13 are x86_64.
- Added notes with respect to the matrix.strategy runner images. The
makefile builds use "-latest" because they don't produce artifacts,
while (*) the CMake builds enumerate the images for which artifacts (+)
are produced and the runner image's name is part of the artifact.
(*) "Whilst" for the rest of the Anglosphere.
(+) "Artefact" for the rest of the Anglosphere.
- Fix comma separator code segmentation fault: "ndigit - 3" can become a
very large unsigned number for ndigit < 3.
- dir_cmd: Allocate WildName from heap to reduce stack pressure.
- Github CI/CD: Remnant symlink issue reappeared, afflicting the
makefile-based build. For better or worse, the workaround is now
dependent on specific Python versions that must be removed, unlinked
and any remnant symlinks that HomeBrew decided it needed to install in
/usr/local/bin. The Python upgrade is triggered by the sdl2_ttf
package.
According to the Github image maintainers, this is an old, known issue
in macOS images that originates inside of Homebrew.
Move the PowerShell code from .github/workflow/cmake-builds.yml into its
own script, cmake/github_v141_xp.ps1, to keep cmake-buils.yml readable.
The script also facilitates synchronizng with the Chocolatey installer's
Wait-VSIstallerProcesses function easier (from which this this code is
derived.)
cmake-builds.yml: Check the output from Get-VSSetupInstance and
Set-VSSetupInstance. Empty (or null) output indicates that the v141_xp
install did not complete successfully. Build process will bail when that
happens.
cmake/v141_xp_install.ps1: Unused and now unnecessary script.
Remove windows_build.yml due to a MS compiler enforcement change. Build
fails because libpng16.lib was compiled with a different compiler
version (VS 2008?) relative to the current VS 2022 installed in the
Github windows-latest runner.
MS decided that libraries must be compiled with a compatible compiler,
preferably the compiler-in-use. While not conclusively traced to a MS
trouble ticket, it seems reasonable to assume there exists a trouble
ticket wherein an older MS compiler generated code that was incompatible
with VS 2022, thereby necessitating the enforcement (speculation: LTO
instrumentation, for example?)
- Bump SIMH_VERSION_MINOR in CMakeLists.txt. This propagates down
through the rest of the CMake infrastructure.
- README-CMake.md, cmake/{GitHub-release.md,cmake-builder.sh}: Update
documentation. (Prettiness.)
- vcpkg.json: Update simh version-string. (Consistency.)
NOTE: Github CI/CD: There has to be an automated way to update version
numbers; researching.
VS installer's startup is not instantaneous and there's some lag in the
CI/CD pipeline. Adjust strategy to wait for startup (20 seconds max) to
make the script more robust. (Doesn't seem to get triggered, but that
doesn't mean it won't happen in the future.)
Add the the following command line flags:
--force: Forces VS instance termination, if any are running.
(Unclear impact. Paranoia.)
--norestart: Delay reboot, if reboot needed. (Probable reason why
(Most likely reason why installs were incomplete.)
--installWhileDownloading: Self-explanitory. (Unclear impact.)
"Get-VSSetupInstance/Select-VSSetupInstance" will report a VS
instance ID if successful, e.g.:
DEBUG: Get-VSSetupInstance/Select-VSSetupInstance
InstanceId : 8d19910a
DisplayName : Visual Studio Enterprise 2022
InstallationVersion : 17.6.33815.320
InstallationPath : C:\Program Files\Microsoft Visual Studio\2022\Enterprise
InstallDate : 6/20/2023 9:38:11 PM
Useful output in the GH CI/CD log for future debugging.
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.
* CMake build infrastructure
The squashed commit that builds and packages releases for the SIMH
simulator suite with CMake, version 3.14 or newer.
See README-CMake.md for documentation.
- Builds x86 and x64 regular snapshots.
x64: Mon Wed Fri
x86: Tue Thu Sat
ARM: Mon Thu Sun (ARM not enabled)
- Builds x64 on closed pull request, Release
- Manual trigger allows selection of ref, platform,
architecture, config, disposition
- Releases and daily snapshots are deployed automagically
- VS Project 2022 files updated for ARM, but not setup for
cross-builds (BuildROMs) or tested on ARM (no hardware)
- Fix makefile tests for cygwin
- Configure run on push and pull requests
- Use new macos and ubuntu OS images
- Add missing simulators from the build list
- Add potential LTO option for makefile builds
