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