docs: Windows CI is green, log-verified; scope the w32-pthreads fallback

Records the outcome of f27b1c0 against the actual job log rather than the
job status: the from-source libobs bootstrap configures/builds/installs,
find_package(libobs) resolves through .deps/cmake/libobs, all 6 CTest suites
pass, and build\package\bin\64bit\streamer-tools-camera.dll (136,192 bytes)
is staged beside livekit.dll and livekit_ffi.dll. First completed green
Windows run on this repository. That also retires three separately-unproven
items at once -- the -A x64 fix, the PowerShell rewrite of the Windows steps,
and the add_subdirectory(deps/w32-pthreads) bootstrap patch.

The log also settles which branch of the new code ran: the "w32-pthreads_DIR
not set" message means OBS's own exported package was at
.deps/cmake/w32-pthreads/ the whole time and the fallback find module was
never loaded. The export was never missing, only unfindable -- worth
recording, because "w32-pthreads has no install rules" was the first
hypothesis and it was wrong.

Also narrows when that fallback is exposed at all. It reads artifacts out of
.deps/ and nowhere else, so it is only appended to CMAKE_MODULE_PATH when
this repo's own bootstrap actually produced an obs-studio tree there. A
developer building against an external OBS SDK (STPLUGIN_BOOTSTRAP_OBS=OFF,
or an explicit -Dlibobs_DIR=...) stays on CMake's normal search, where
whatever w32-pthreads package their SDK provides can still win -- a find
module that could only ever fail would have made their error worse, not
better. Linux reconfigures unchanged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE

CMakeLists.txt

@@ -249,9 +249,20 @@ if(OS_WINDOWS AND NOT w32-pthreads_DIR)
         # would shadow OBS's own exported package on every build, and its
         # real export is the better answer whenever it is present.
         #
-        # Reaching here means the bootstrap install did not produce the
+        # ...and only when this repo's own bootstrap actually ran, which is
-        # export, so say exactly what IS in .deps/cmake/ -- the next CI log
+        # the only situation the fallback module knows how to serve: it reads
-        # then answers the question directly instead of costing another run.
+        # artifacts out of .deps/ and nowhere else. A developer building
+        # against their own external OBS SDK (STPLUGIN_BOOTSTRAP_OBS=OFF, or
+        # an explicit -Dlibobs_DIR=...) must be left on CMake's normal search
+        # so that whatever w32-pthreads package their SDK does provide still
+        # wins -- exposing a find module that can only ever fail would turn
+        # their build's outcome into a worse error, not a better one.
+        file(GLOB _stplugin_deps_obs_trees "${CMAKE_CURRENT_SOURCE_DIR}/.deps/obs-studio-*")
+        if(_stplugin_deps_obs_trees)
+            # Reaching here means the bootstrap ran but its install did not
+            # produce the export, so say exactly what IS in .deps/cmake/ --
+            # the next CI log then answers the question directly instead of
+            # costing another run.
             file(GLOB _stplugin_deps_cmake_dirs "${CMAKE_CURRENT_SOURCE_DIR}/.deps/cmake/*")
             message(STATUS
                 "No w32-pthreadsConfig.cmake at ${_stplugin_win_pthreads_dir}; "
@@ -262,6 +273,7 @@ if(OS_WINDOWS AND NOT w32-pthreads_DIR)
             list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/windows/find-fallback")
         endif()
     endif()
+endif()
 
 find_package(libobs QUIET)
 

README.md

@@ -44,15 +44,20 @@ real streamer-tools API shape, and pushes decoded frames into
 
 It has **not been run in the OBS GUI on any platform.** macOS builds the real
 module in CI but its artifact is not yet loadable (see the macOS packaging gap
-under CI). Windows CI has **failed on every completed run so far**. The
+under CI).
-`-A x64` argument fix is now confirmed working — the run carrying it got as
+
-far as building libobs — but it exposed a deeper blocker: OBS 30.0.2's
+**Windows CI is now green.** The run at `f27b1c0` is the first completed
-opt-in modern CMake path never defines the `OBS::w32-pthreads` target its own
+green Windows job on this repository: the from-source libobs bootstrap
-Windows libobs links against. A targeted bootstrap patch for that gap has been
+configures, builds and installs, `find_package(libobs)` resolves, all 6 CTest
-pushed but not yet confirmed by a completed green run. The PowerShell rewrite
+suites pass, and `build\package\bin\64bit\streamer-tools-camera.dll`
-of the Windows steps is also still unproven. See "Where the Windows bootstrap
+(136,192 bytes) is staged next to `livekit.dll` and `livekit_ffi.dll` — read
-got to" under CI below for the trace and the options, and check current CI
+out of the job's own log body, not inferred from the job status. That also
-status rather than trusting this paragraph's age.
+retires three previously-unproven items in one go: the `-A x64` argument fix,
+the PowerShell rewrite of the Windows steps, and the `add_subdirectory`
+patch for `OBS::w32-pthreads`. Windows is still **unverified in the OBS GUI**,
+exactly like the other two platforms. See "Where the Windows bootstrap got
+to" under CI below for the whole trace, and check current CI status rather
+than trusting this paragraph's age.
 
 See "What is verified, and how" below for exactly what has and has not been
 checked, and "Testing this by hand" for what a human still needs to do.
@@ -323,8 +328,12 @@ Windows is by far the slowest job — the `lukka/get-cmake` step alone takes
 7-15 minutes on `winvm-builder`, and the runner serialises jobs, so a burst of
 pushes leaves a queue that takes an hour to drain.
 
-**The honest record: every completed Windows CI run on this branch has
+**The honest record, as it stood before `f27b1c0`: every completed Windows CI
-failed.** The first 7 failures were all at commits predating the `-A x64` fix
+run on this branch had failed.** (`f27b1c0` is the one that finally went
+green — see "After the w32-pthreads target" at the end of this section. The
+history below is kept because each dead end in it is a real constraint
+someone will otherwise rediscover.) The first 7 failures were all at commits
+predating the `-A x64` fix
 below. The 8th, at `edb0c02` — the first commit that actually carries that fix
 — has since completed, and it is the informative one: **the `-A x64` fix
 worked, and Windows failed further along, on something else.** A later run
@@ -452,12 +461,11 @@ getting past it, the second is still unproven:
    `58f4832`'s failure says nothing about the `w32-pthreads` blocker; that
    result comes from `edb0c02` alone.
 
-Until a Windows run completes green, Windows should be treated as unverified
+(Superseded by the next subsection: the `w32-pthreads` blocker described above
-beyond "the core library and the WinHTTP backend compile and their tests
+*was* the next thing solved, and the `add_subdirectory` patch and the
-pass", which earlier (failing-job) runs did show before failing later in the
+PowerShell rewrite are both now proven by a completed green run. What stands
-job. The `w32-pthreads` blocker above is the next thing to solve, and it is
+from this subsection is its reasoning — why `ENABLE_UI=OFF` exposes the gap,
-upstream's problem to work around rather than a defect in this repo's
+and why re-enabling Qt or bumping the OBS pin is not the answer.)
-bootstrap.
 
 ### After the w32-pthreads target: the w32-pthreads *package*
 
@@ -539,5 +547,32 @@ fallback find module was exercised separately by deleting that package, with
 `find_package` resolving through MODULE mode to it instead. A full Linux
 configure of this repo is unchanged (both blocks are inside `if(OS_WINDOWS)`,
 and the upstream `find_dependency` is inside `if(MSVC)`, so macOS and Linux
-are pure no-ops). Whether the real Windows runner now gets to a
+are pure no-ops).
-`streamer-tools-camera.dll` is what the CI run on this commit has to show.
+
+**Confirmed on the real runner.** The Windows job for `f27b1c0` completed
+green, and its log body — not just its status — shows the whole chain:
+
+```
+-- w32-pthreads_DIR not set; libobsConfig.cmake's find_dependency(w32-pthreads
+   REQUIRED) hits the same OBS_CMAKE_DESTINATION=cmake search-suffix problem as
+   libobs itself, so pointing it directly at the from-source install:
+   ...\.deps\cmake\w32-pthreads
+-- libobs found (...\.deps\cmake\libobs) -- building OBS adapter module
+   streamer-tools-camera.vcxproj -> ...\build\obs-adapter\Release\streamer-tools-camera.dll
+100% tests passed out of 6
+    Directory: ...\build\package\bin\64bit
+-a----   3078656 livekit.dll
+-a----  25008640 livekit_ffi.dll
+-a----    136192 streamer-tools-camera.dll
+```
+
+Note which branch that log took: the `w32-pthreads_DIR` message means the
+package config really was sitting at `.deps/cmake/w32-pthreads/` all along and
+the fallback find module was never loaded. The export was never missing — only
+unfindable. Linux and macOS were green in the same run, confirming the no-op.
+
+The one piece of noise left in that log is the tolerated
+`UI/obs-frontend-api/cmake_install.cmake` error, which now repeats once per
+CMake re-configure because Visual Studio's `ZERO_CHECK` target re-runs the
+bootstrap during the build. It is cosmetic and pre-dates this change, but it
+makes the Windows log harder to read than it should be.