feat(build): a new version's game files linked from a version built from the same .nup #58

Open

madebyjordan wants to merge 1 commit from madebyjordan/LongshotLauncher:feat/romfs-from into main

madebyjordan commented

2026-11-14 04:24:13 +00:00

First-time contributor

Why

Every new version, and every update into its own folder, read the player's .nup again: 26 GB written once more, and 26 GB more disk space for each version, for game files the PC already has. This passes the builder the folder of a version already built from the same .nup, so it hard-links the game files from it instead (Longshot MagicBeanDev/Longshot#360, LONGSHOT_ROMFS_FROM).

What changed

Core/BuildRegistry.cs: SameGameFiles(nup, folder) picks another build made from the same .nup: the one updated last whose folder still has its game files, and never the new build's own folder. It returns null when there's none.
App/ViewModels/BuildStepViewModel.cs: for a .nup build, the build step passes that folder as BuildRequest.RomfsFrom. No visual change.
Core/MakeGameCommand.cs: BuildRequest.RomfsFrom becomes LONGSHOT_ROMFS_FROM for a .nup build. For any other build it's removed from the environment, so a value set on the PC isn't passed on.
tests/launcher_core:
- SameGameFiles' choice: the newest with game files, another .nup, none on disk, and never its own folder.
- The variable is set for a .nup only.

Compatibility

A builder that doesn't know the variable (one without Longshot MagicBeanDev/Longshot#360) ignores it and unpacks the .nup as before.
make_game checks the folder's own record of its unpack (.longshot_romfs: the .nup's name and size) before it links anything. A wrong or stale folder is passed over, and the .nup is read.

Testing

tests/test_launcher_core.py on Windows (.NET 10.0.404): every check up to SavesChecks passes, including the new ones in RegistryChecks and CommandChecks (Require throws on the first failure). The run can't finish on this PC on launcher main either: main stops at ReleaseChecks (the signed release fixtures, checked out with Windows line endings). With the Windows fixes of a separate branch merged for the run, it stops at SavesChecks, which makes a symbolic link, and this Windows user has no right to (no Developer Mode).
The builder side was measured on the same PC (Ryzen 5 5600, NVMe, Windows 11), alternated, with the OoT .nup and a second game folder: the .nup unpacked in 146.8 s (26.27 GB written) against linked in 131.4 s (nothing written, all 186,583 files hard links). Details are in Longshot MagicBeanDev/Longshot#360.
Not run: a whole second-version build through the launcher's window. The command it builds and its environment are what the checks cover.

Rebased on main @ 01f2797.

## Why Every new version, and every update into its own folder, read the player's .nup again: 26 GB written once more, and 26 GB more disk space for each version, for game files the PC already has. This passes the builder the folder of a version already built from the same .nup, so it hard-links the game files from it instead (Longshot https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/360, `LONGSHOT_ROMFS_FROM`). ## What changed - `Core/BuildRegistry.cs`: `SameGameFiles(nup, folder)` picks another build made from the same .nup: the one updated last whose folder still has its game files, and never the new build's own folder. It returns null when there's none. - `App/ViewModels/BuildStepViewModel.cs`: for a .nup build, the build step passes that folder as `BuildRequest.RomfsFrom`. No visual change. - `Core/MakeGameCommand.cs`: `BuildRequest.RomfsFrom` becomes `LONGSHOT_ROMFS_FROM` for a .nup build. For any other build it's removed from the environment, so a value set on the PC isn't passed on. - `tests/launcher_core`: - `SameGameFiles`' choice: the newest with game files, another .nup, none on disk, and never its own folder. - The variable is set for a .nup only. ## Compatibility - A builder that doesn't know the variable (one without Longshot https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/360) ignores it and unpacks the .nup as before. - make_game checks the folder's own record of its unpack (`.longshot_romfs`: the .nup's name and size) before it links anything. A wrong or stale folder is passed over, and the .nup is read. ## Testing - `tests/test_launcher_core.py` on Windows (.NET 10.0.404): every check up to `SavesChecks` passes, including the new ones in `RegistryChecks` and `CommandChecks` (`Require` throws on the first failure). The run can't finish on this PC on launcher main either: main stops at `ReleaseChecks` (the signed release fixtures, checked out with Windows line endings). With the Windows fixes of a separate branch merged for the run, it stops at `SavesChecks`, which makes a symbolic link, and this Windows user has no right to (no Developer Mode). - The builder side was measured on the same PC (Ryzen 5 5600, NVMe, Windows 11), alternated, with the OoT .nup and a second game folder: the .nup unpacked in 146.8 s (26.27 GB written) against linked in 131.4 s (nothing written, all 186,583 files hard links). Details are in Longshot https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/360. - Not run: a whole second-version build through the launcher's window. The command it builds and its environment are what the checks cover. Rebased on main @ 01f2797.

madebyjordan added 1 commit

2026-11-14 04:24:13 +00:00

feat(build): a new version's game files linked from a version built from the same .nup

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Compile and test (pull_request) Blocked by required conditions

Details

69a6d03e84

Each new version, and each update into its own folder, read the player's .nup again: ~25 GB written once more (about 3
minutes on an NVMe drive, longer on a hard disk) and that much disk space again, for game files the PC already has.

- BuildRegistry.SameGameFiles: another build made from the same .nup, the one updated last whose folder has its game files,
  never the new build's own folder.
- The build step passes its folder in BuildRequest.RomfsFrom, and MakeGameCommand sets LONGSHOT_ROMFS_FROM for a .nup
  build (removed otherwise, so one set on the PC is not passed on). make_game hard-links that folder's game files after
  checking its record of the unpack (Longshot's make_game.py, LONGSHOT_ROMFS_FROM); a builder that does not know the
  variable reads the .nup as before.
- tests/launcher_core: SameGameFiles' choice, and the variable for a .nup only.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

madebyjordan referenced this pull request from MagicBeanDev/Longshot

2026-11-14 04:24:32 +00:00

feat(build): a new version's game files hard-linked from another game folder of the same .nup #360

madebyjordan referenced this pull request from MagicBeanDev/Longshot

2026-11-14 04:25:32 +00:00

perf(build): a first build in under 10 minutes: what was measured, and a proposal (a clang-free cold tier) #362