https://gitlab.synchro.net/main/sbbs/-/commit/7466e94ea5e801782f664ae8
Added Files:
src/doors/build.bat
Log Message:
doors: add a top-level build.bat, the Win32 twin of build.sh

build.sh drives the doors that build on a Unix toolchain, and nothing did
the same for Windows -- where the story differs enough that forwarding to build.sh was never an option. src/doors/build.bat is the same umbrella for MSVC: it drives all eight Win32-buildable targets, keeps going when one
fails, and prints a pass/fail summary, exiting non-zero if any failed.

Seven of the eight are the modern doors, each of which already ships its
own build.bat. The eighth is The Clans, built from src/clans.sln with
MSBuild -- the one legacy door with a Windows project. The rest are
make(1) trees that link ../odoors and assume a Unix toolchain, so -l
reports them as having no Windows build instead of failing them one by
one.

Where it differs from build.sh it says why in the header: there is no
libODoors prerequisite step, because the Win32 ODoorW.lib is prebuilt and tracked; Win32 is the only target, since one Win32 door binary serves a
Win64 host too and three of the doors refuse x64 outright; and there is no debug build, because no per-door build.bat takes the argument. Both are
refused up front rather than passed down. Cleaning removes build-msvc and leaves build/ to build.sh, since a shared checkout can hold both.

Named targets build a subset, "clean"/"clean all", -l and -q all mean what
they do in build.sh, and per-target logs land in the same .build-logs/.

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/94a98783870f3c852a065640
Modified Files:
src/doors/build.bat
Log Message:
doors: keep build.bat's working state out of the child builds

build.bat kept its per-target exit status in RC, its build type in CONFIG
and its target in PLATFORM. Every door build inherits this environment --
cmd has no way to hide a variable from a child -- and all three names mean something down there: CMake reads %RC% as the resource compiler, and
MSBuild turns any environment variable into a property of the same name.

The symptom was syncrpg failing its CMake compiler check on the sixth
target of a full run, and only there. The earlier doors use the Visual
Studio generator, where MSBuild picks the resource compiler, while syncrpg configures with Ninja, where CMake honours $ENV{RC}. By then RC was 0 from
an earlier target's exit status, so find_program looked for a resource
compiler named "0" and found one: the file literally named 0 that ships in Synchronet's exec dir, which is on PATH on a BBS host.

Rename the three to SB_RC/SB_CONFIG/SB_PLATFORM and say why at the top, so
the next variable added here does not quietly reintroduce it.

A poisoned CMakeCache.txt outlives the fix -- a cache entry beats the environment -- so a tree configured during the bug needs a
"build.bat clean <door> all" before it will configure again.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net