2 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Sonnet 5	f27b1c0b45	Fix Windows configure: point find_package at OBS's exported w32-pthreads ... The libobs_DIR fix in 79de5e8f worked -- libobsConfig.cmake now loads on the Windows runner -- and immediately exposed the next link in the same chain. obs-studio's libobsConfig.cmake.in carries, under if(MSVC), a hard find_dependency(w32-pthreads REQUIRED) because libobs/cmake/os-windows.cmake links PUBLIC OBS::w32-pthreads. That lookup failed and aborted the whole configure. The cause is not a missing export, which was the first hypothesis: deps/w32-pthreads/CMakeLists.txt ends in target_export(w32-pthreads), the same helper libobs itself uses, so the install(TARGETS ... EXPORT), install(EXPORT ... NAMESPACE OBS::) and generated w32-pthreadsConfig.cmake all exist and all run -- CMake would have hard-errored at generate time if w32-pthreads were in no export set, and our own patch adds it under the libobs subtree, which installs before the tolerated obs-frontend-api install error stops the rest. It is the same search-path mismatch libobs itself had: target_export installs to <prefix>/${OBS_CMAKE_DESTINATION}/<target>/, which on Windows is <prefix>/cmake/w32-pthreads/ -- a shape find_package's Config-mode suffixes never search. So apply the same remedy CMake's own error message suggests, and apply it before the find_package(libobs) call that transitively triggers the find_dependency. Also adds a fallback Findw32-pthreads.cmake, reached only when that export is genuinely absent, which reconstructs OBS::w32-pthreads from the bootstrap's artifacts, and a repair for a locationless imported target mirroring the existing OBS::libobs one. The fallback deliberately lives in cmake/windows/find-fallback/ rather than cmake/windows/, which osconfig.cmake already puts on CMAKE_MODULE_PATH: a find module there would shadow OBS's real exported package on every build, since MODULE mode is tried first. Verified on Linux (this is a Linux sandbox) by reconstructing the exact failure -- a stub libobsConfig.cmake with the same find_dependency, reached through libobs_DIR -- and confirming it fails without this block and passes with it, and separately that deleting the package routes find_package through the fallback module instead. A full Linux configure of the repo is unchanged; both new blocks are inside if(OS_WINDOWS) and the upstream find_dependency is inside if(MSVC), so macOS and Linux are no-ops. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:40:38 -07:00
shadowdaoandClaude Sonnet 5	8494485351	ci: build the real OBS adapter on all three platforms ... Two things: unbreak the Windows compile, and give macOS/Windows a libobs. MSVC fix. test_json.cpp failed to compile on the Windows runner with "a universal-character-name specifies an invalid character" and "illegal escape sequence" -- MSVC still forms escape sequences and universal-character-names INSIDE raw string literals, which it must not. Every JSON input containing a backslash is now built by string concatenation from a single kBS constant, which also sidesteps the separate murky corner of translation phase 1 where a doubled backslash immediately followed by 'u' has historically been treated inconsistently. Same 158 checks, no behaviour change. OBS SDK bootstrap for macOS/Windows. Adopts obsproject/obs-plugintemplate's buildspec machinery -- buildspec.json plus cmake/common/buildspec_common.cmake and cmake/{macos,windows}/buildspec.cmake -- so those two platforms get a real libobs and build the actual plugin module instead of only the core library. Linux is untouched and still uses Ubuntu's libobs-dev (-DSTPLUGIN_BOOTSTRAP_OBS=OFF); the bootstrap only runs where there is no system package. Trimmed against upstream, each change recorded in the file that makes it: - qt6 is dropped from dependencies_list on both platforms. The properties UI is plain obs_properties_* and nothing here links Qt. - The OBS sub-build builds and installs the `libobs` target, not `obs-frontend-api`. Building the frontend API is what would drag Qt back in, and this plugin never calls it. - The sub-build is configured with ENABLE_UI=OFF and ENABLE_SCRIPTING=OFF as well as upstream's ENABLE_FRONTEND=OFF: the pinned OBS predates ENABLE_FRONTEND and gates its Qt-dependent UI on ENABLE_UI, so without this it configures the whole OBS UI and demands Qt anyway. - Only the Release configuration is built and installed, not Debug as well. Nothing consumes a debug libobs and it doubles the slowest CI step. - Only the dependency-acquisition modules are vendored. The template's compilerconfig/defaults/helpers/xcode modules drive its own target and bundle layout, which this project does not use. obs-studio is pinned to 30.0.2, deliberately low: OBS refuses to load a module built against a NEWER libobs than the one running it and accepts older ones, so this pin IS the minimum OBS version users need. 30.0.2 is also exactly what Ubuntu 24.04's libobs-dev ships, which puts all three platforms on one floor, and it supports the modern CMake layout the bootstrap drives via -DOBS_CMAKE_VERSION=3.0.0. prebuilt is obs-deps 2023-11-03 with the hashes obs-studio 30.0.2's own buildspec.json publishes; the obs-studio source archive hashes were computed from the GitHub tag archives. The workflow also prints what was actually produced on each platform (ldd / otool / dir over build/package) and uploads it as an artifact, so "does this even link against libobs" is answered by CI output rather than assumed. Verified locally: the Linux path is unchanged by all of this -- a fresh configure still finds libobs-dev, and ctest is 6/6. The macOS and Windows bootstrap can only be verified by CI; that is what this push is for. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:02:17 -07:00