From 1f342b1971fc80aebaf4ebfab3d08d026fc9842f Mon Sep 17 00:00:00 2001 From: Josh Knapp Date: Mon, 7 Sep 2026 05:56:18 -0700 Subject: [PATCH] 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 Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE --- CMakeLists.txt | 34 +++++++++++++++-------- README.md | 73 +++++++++++++++++++++++++++++++++++++------------- 2 files changed, 77 insertions(+), 30 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 15bfea3..06adcc5 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -249,17 +249,29 @@ 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 - # 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}; " - "OBS CMake packages actually installed under .deps/cmake: " - "'${_stplugin_deps_cmake_dirs}'. Falling back to this repo's own " - "Findw32-pthreads.cmake, which builds OBS::w32-pthreads straight " - "from the bootstrap's build artifacts.") - list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/windows/find-fallback") + # ...and only when this repo's own bootstrap actually ran, which is + # the only situation the fallback module knows how to serve: it reads + # 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}; " + "OBS CMake packages actually installed under .deps/cmake: " + "'${_stplugin_deps_cmake_dirs}'. Falling back to this repo's own " + "Findw32-pthreads.cmake, which builds OBS::w32-pthreads straight " + "from the bootstrap's build artifacts.") + list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/windows/find-fallback") + endif() endif() endif() diff --git a/README.md b/README.md index d9bc777..47d4038 100644 --- a/README.md +++ b/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 -`-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 -opt-in modern CMake path never defines the `OBS::w32-pthreads` target its own -Windows libobs links against. A targeted bootstrap patch for that gap has been -pushed but not yet confirmed by a completed green run. The PowerShell rewrite -of the Windows steps is also still unproven. See "Where the Windows bootstrap -got to" under CI below for the trace and the options, and check current CI -status rather than trusting this paragraph's age. +under CI). + +**Windows CI is now green.** The run at `f27b1c0` is the first completed +green Windows job on this repository: the from-source libobs bootstrap +configures, builds and installs, `find_package(libobs)` resolves, all 6 CTest +suites pass, and `build\package\bin\64bit\streamer-tools-camera.dll` +(136,192 bytes) is staged next to `livekit.dll` and `livekit_ffi.dll` — read +out of the job's own log body, not inferred from the job status. That also +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 -failed.** The first 7 failures were all at commits predating the `-A x64` fix +**The honest record, as it stood before `f27b1c0`: every completed Windows CI +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 -beyond "the core library and the WinHTTP backend compile and their tests -pass", which earlier (failing-job) runs did show before failing later in the -job. The `w32-pthreads` blocker above is the next thing to solve, and it is -upstream's problem to work around rather than a defect in this repo's -bootstrap. +(Superseded by the next subsection: the `w32-pthreads` blocker described above +*was* the next thing solved, and the `add_subdirectory` patch and the +PowerShell rewrite are both now proven by a completed green run. What stands +from this subsection is its reasoning — why `ENABLE_UI=OFF` exposes the gap, +and why re-enabling Qt or bumping the OBS pin is not the answer.) ### 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 -`streamer-tools-camera.dll` is what the CI run on this commit has to show. +are pure no-ops). + +**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.