fix: statically link the Windows standalone CLI release (SYS-W11-06)

Downloaded and verified the real published meshcraft-cli-windows
artifact from the first fully-green windows-2022 CI run, per
SYS-W11-06's amended acceptance criteria (extract outside any build
tree, run --version, reproduce the MC3->MCB/GLB fixture and check its
SHA-256). The artifact failed at the first step: mc3togltf.exe wouldn't
even start (STATUS_DLL_NOT_FOUND under a MinGW+Wine repro of the exact
downloaded files) -- the artifact bundles only the two .exe files, but
mc3togltf.exe dynamically links Manifold and tinyxml2 (both inherit
Manifold's own BUILD_SHARED_LIBS=ON default) plus the MinGW toolchain's
own runtime (libgcc_s_seh-1.dll/libwinpthread-1.dll/libstdc++-6.dll),
none of which the "Publish qualified Windows CLI artifacts" step
stages.

Rather than enumerating and uploading every DLL (fragile, and the
POST_BUILD $<TARGET_RUNTIME_DLLS:...> copy step doesn't even see the
raw MinGW compiler runtime DLLs, only proper CMake library targets),
fixed this the same way Mc3/Mcb/mc3togltf_lib already are: link
everything statically. Added -DBUILD_SHARED_LIBS=OFF and
-DCMAKE_EXE_LINKER_FLAGS="-static -static-libgcc -static-libstdc++" to
the standalone-windows job's shared configure step (all 4 components).

Also fixed a real CMake gotcha this surfaced: mc3togltf_stage_runtime_
dlls()'s POST_BUILD command failed outright once a target had zero
DLL dependencies -- $<TARGET_RUNTIME_DLLS:target> expands to nothing,
and `cmake -E copy_if_different` with no source arguments is an error,
not a no-op. Fixed with the documented $<IF:$<BOOL:...>,copy_if_different,true>
workaround.

Verified via a real MinGW+Wine repro of the exact static-linked
binaries: mc3togltf.exe and mc3tomcb.exe both now have zero DLL
dependencies, both run --version standalone, and both reproduce
test/house.mc3.xml's MC3->GLB/MCB conversion byte-identical to the
existing fixture SHA-256 hashes
(0ef25953c8bce.../4157f107e277a...). Also reran the full 28-test
standalone mc3 suite under this same static config: 28/28 pass (one
apparent timeout on a solo rerun was Wine process contention, not a
real failure, matching an already-known pattern from earlier tonight).

Author: robertvokac

.github/workflows/ci.yml

@@ -102,8 +102,22 @@ jobs:
           $components = @('mc3', 'mcb', 'mc3togltf', 'mc3tomcb')
           foreach ($component in $components) {
             $buildDir = "build/$component"
+            # BUILD_SHARED_LIBS=OFF + static-linking the MinGW runtime: without
+            # this, mc3togltf.exe links against Manifold/tinyxml2 as DLLs
+            # (they inherit Manifold's own BUILD_SHARED_LIBS=ON default) AND
+            # the MinGW toolchain's own runtime (libgcc_s_seh-1.dll/
+            # libwinpthread-1.dll/libstdc++-6.dll) -- none of which the
+            # "Publish qualified Windows CLI artifacts" step below stages
+            # alongside the .exe, so the *published* artifact fails to start
+            # at all with STATUS_DLL_NOT_FOUND outside this build tree.
+            # Confirmed via a real downloaded artifact + MinGW/Wine repro
+            # (2026-07-27, SYS-W11-06 verification): fully static removes
+            # every DLL dependency and produces byte-identical MC3->MCB/GLB
+            # output to the dynamic build.
             cmake -S $component -B $buildDir -G Ninja `
-              -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
+              -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON `
+              -DBUILD_SHARED_LIBS=OFF `
+              -DCMAKE_EXE_LINKER_FLAGS="-static -static-libgcc -static-libstdc++"
             cmake --build $buildDir --parallel 2
             ctest --test-dir $buildDir --output-on-failure --parallel 2
           }
@@ -119,12 +133,11 @@ jobs:
 
       # SYS-W11-08: bundle the same notices/SHA-256 manifest the Linux
       # meshcraft_cli_release archive gets, so the Windows artifact isn't a
-      # bare, unverifiable pair of executables. Does not attempt to stage
-      # Manifold/tinyobjloader runtime DLLs here -- that is a separate,
-      # already-tracked gap (the in-tree ctest run above can currently fail
-      # with STATUS_DLL_NOT_FOUND for the same underlying reason), and adding
-      # a manifest for an incomplete artifact is still strictly better than
-      # no manifest at all.
+      # bare, unverifiable pair of executables. No runtime DLLs to stage
+      # (fixed 2026-07-27, SYS-W11-06 verification): the configure step above
+      # now links everything -- Manifold, tinyxml2, and the MinGW runtime
+      # itself -- statically, so these two .exe files have zero third-party
+      # DLL dependencies at all.
       - name: Stage release manifest and notices
         shell: pwsh
         run: |

mc3togltf/CMakeLists.txt

@@ -111,8 +111,16 @@ endif()
 # is a no-op there.
 function(mc3togltf_stage_runtime_dlls target)
     if(WIN32)
+        # $<TARGET_RUNTIME_DLLS:...> expands to nothing when a target has no
+        # DLL dependencies at all (e.g. a fully statically-linked build) --
+        # `cmake -E copy_if_different` with zero source arguments is itself
+        # an error (prints usage, fails the build), not a harmless no-op. Pick
+        # the `true` no-op subcommand instead of `copy_if_different` in that
+        # case via $<IF:$<BOOL:...>,...>, a documented workaround for this
+        # exact generator-expression gotcha.
         add_custom_command(TARGET ${target} POST_BUILD
-            COMMAND ${CMAKE_COMMAND} -E copy_if_different
+            COMMAND ${CMAKE_COMMAND} -E
+                    $<IF:$<BOOL:$<TARGET_RUNTIME_DLLS:${target}>>,copy_if_different,true>
                     $<TARGET_RUNTIME_DLLS:${target}>
                     $<TARGET_FILE_DIR:${target}>
             COMMAND_EXPAND_LISTS