Fix Windows build: fetch GLFW/ImGui without Git

[jmossymoss]

Problem

Windows configure failed with:

error: could not find git for clone of glfw-populate
CMake step for glfw failed: 1

app/CMakeLists.txt used FetchContent with GIT_REPOSITORY, so CMake required git on PATH. build.bat treated Git as optional and skipped installing it, which matches the failure when building with a local OCCT tree and no Git.

Fix

• Fetch pinned GLFW 3.4 and ImGui v1.90.9-docking as GitHub tag zip archives (URL + URL_HASH) instead of cloning.
• Set CMP0135 NEW when available to avoid archive-timestamp warnings on newer CMake.
• Soft-install Git from Chocolatey when missing (still not required for the zip fetch).
• Document the failure mode and recovery in WINDOWS_BUILD.md.

Verification

• Confirmed CMake URL FetchContent populates both archives with git removed from PATH.
• SHA-256 hashes recorded for the pinned tag archives.

How to re-run on Windows

1. Pull this branch (or merge).
2. Delete build\CMakeCache.txt (and build\_deps if present).
3. Re-run build.bat.

No Git install is required for the GLFW/ImGui download; internet access at configure time still is.

  

---

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[devin-ai-integration]

Code review (Devin) — PR #53

Small, well-targeted change (e3f1636): switching the GLFW/ImGui FetchContent calls from
GIT_REPOSITORY to URL + URL_HASH, plus docs. Pinning by SHA256 and setting CMP0135 are both
right, and dropping the git dependency genuinely removes the most common "CMake + VS Build Tools
only" Windows failure.

1. build.bat now installs Git — which the same commit says isn't needed

echo [3/5] Checking Git...
where git >nul 2>&1
if %errorLevel% neq 0 (
    call :ensure_choco
    ...
    choco install git -y --no-progress >> "%LOG%" 2>&1

The commit message, WINDOWS_BUILD.md, and the [5/5] banner all now say Git is not required, but
the script escalates to a Chocolatey install of it. :ensure_choco needs an administrator prompt, so
for a non-admin tester this turns a previously silent "skipping" into a visible error path, and for
an admin tester it silently installs a package they were just told they don't need. I'd revert step
3 to the old informational skip (or gate the install behind an explicit --with-git flag).

Mechanically the block is fine — setlocal enabledelayedexpansion is set at line 7, so !errorLevel!
and !PATH! expand correctly, and the post-install where git uses the updated PATH.

2. GitHub auto-generated tag archives are the weaker pin

https://github.com/glfw/glfw/archive/refs/tags/3.4.zip is generated on demand; GitHub has
historically changed the compression of these archives, and when that happens your URL_HASH fails
for everyone at once with a confusing "hash mismatch" during configure. GLFW publishes a real release
asset (glfw-3.4.zip under /releases/download/3.4/), which is immutable — worth preferring for
GLFW. ImGui has no release assets, so the tag archive is the only option there; consider a short
troubleshooting entry in WINDOWS_BUILD.md for the hash-mismatch case, since it is now a possible
first-configure failure mode that didn't exist with GIT_TAG.

3. if(POLICY CMP0135) placement

Setting the policy inside the if(TRUE) block works (directory scope), but it applies to everything
after it in this directory, which is a little surprising for a reader. Setting it next to the
cmake_minimum_required/project setup, or via set(CMAKE_POLICY_DEFAULT_CMP0135 NEW), states the
intent more clearly.

4. if(TRUE) (pre-existing)

Not from this PR, but while you're in here: if(TRUE) wrapping the whole fetch block reads as
leftover scaffolding. If ImGui is unconditionally fetched, drop the wrapper.

CI

linux is red with the same assertions as #51 (test_pipeline.cpp:1112/1117 and 3193/3206,
failedFloor == 1), and this PR touches only WINDOWS_BUILD.md, app/CMakeLists.txt, and
build.bat — so the failure is inherited from the shared base, not caused here. Worth confirming
before merge that the base is expected to be red at this revision.