https://gitlab.synchro.net/main/sbbs/-/commit/6287f78200818aa664a596fc
Modified Files:
src/doors/syncscumm/build.bat
Log Message:
syncscumm: bootstrap create_project from its CMake project

build.bat built ScummVM's project generator from devtools/create_project/msvc/create_project.sln, which is not in this tree
and never was: ScummVM's .gitignore blanket-ignores *.sln and *.vcxproj*,
so upstream's bootstrap solution was never carried into the vendored copy.
A fresh checkout therefore failed at step 2 with MSB1009, project file does
not exist.

devtools/create_project/cmake/CMakeLists.txt is tracked and builds the same sources -- ours, with the --synchronet patch -- so configure and build that instead, leaving the tool in the door's own build tree rather than back in
the ScummVM source directory. The door builds from a clean checkout again.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/15985e829639c90cf336f262
Modified Files:
src/doors/syncscumm/build.bat
Log Message:
syncscumm: rebuild create_project.exe on every build

The Win32 build failed at project generation:

[build] Generating MSVC project files (create_project --termgfx) ...
ERROR: Unknown parameter "--termgfx"

create_project is built from the vendored ScummVM sources, which carry a
local patch adding that flag, but build.bat only built it when the .exe did
not already exist. A copy produced before df6c0f44e0 (saver-19-week) --
which renamed the flag from --synchronet -- was therefore reused against sources that no longer offered it. The error names the flag rather than
the stale tool, pointing away from the cause.

Build it unconditionally; CMake's own dependency check keeps the
up-to-date case cheap. The comment above it still called the patch by the flag's old name.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/987bec6be928b0de24aa46ed
Modified Files:
src/doors/syncscumm/build.bat
Log Message:
syncscumm: build with the 64-bit MSBuild

build.bat picked C:\...\MSBuild\Current\Bin\MSBuild.exe, which is a 32-bit process -- and so is every worker node it spawns. This solution builds nine projects under /m, each running cl /MP, and a node's 32-bit address space
does not survive that: once the .NET JIT can no longer allocate, it fails whichever method it happens to be compiling with

System.InvalidProgramException: JIT Compiler encountered an internal
limitation.

Which method that is varies per run, so a single exhaustion produced a different error every time and the CI failures read as unrelated flakes: the
CL task failing in PostExecuteTool, the LIB task failing to instantiate, a compiled Regex inside MSBuild's own Expander, vcpkg's inline GetGlobalProperties task "not found", and bare "MSB4166: Child node N exited prematurely". windows-x86 [syncscumm] failed this way intermittently and
was the only job on that runner ever to fail -- it is the only build here
big enough to run a node out of address space.

Prefer Bin\amd64\MSBuild.exe, falling back to the 32-bit one if no installed
VS 2022 edition ships it. Same MSBuild, 64-bit address space. This is the failure msvc\Directory.Build.props already fixes one layer down for the compiler itself (PreferredToolArchitecture=x64, after the 32-bit cl.exe host ran out of address space under /MP); MSBuild needed the same treatment.

Introduced in 745c1c542b, which added this build.

Reproduced locally: a clean build.bat run under the 32-bit MSBuild died with the CL and LIB tasks both throwing InvalidProgramException, and under
Bin\amd64 the same tree builds through to build-msvc\Release\syncscumm.exe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KvZbcp3SQ7xt7bgpRRxvpg
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/daeb0358b9703ef6aa87abd8
Modified Files:
src/doors/syncscumm/build.bat
Log Message:
syncscumm: drop the backend junction on every build.bat exit

build.bat replaces the tracked backends/platform/termgfx symlink with a junction to door\ and used to leave it in place. The next CI checkout in
that runner slot replaces the junction with the symlink file again and, on
the way, deletes door\'s files through it -- without restoring them in the
same pass. Usually a different job absorbed that and the following
checkout put the files back, but on 2026-10-29 two windows-x86 [syncscumm]
jobs ran back to back in VERT's slot 0, and job 1832617 found door\ empty: "door does not appear to contain CMakeLists.txt".

- Call :drop_junction on success and on the :error path, so no junction
survives into the next checkout.
- :drop_junction tests the junction as a directory rather than via
module.mk, so a junction to an emptied door\ is still removed.
- Step 1 removes a stale junction with rmdir: del /Q on a junction
deletes the files in its target.
- Step 1 restores any door\ file git reports deleted, covering stale
junctions already left in other runner slots. Only deleted files are
checked out, so local edits are kept.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net