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
This commit is contained in:
Claude Sonnet 5
+23
-11
@@ -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()
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user