b2fac34a5a131a38c01602255033055d684c02c6
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  shadowdaoandClaude Sonnet 5
|
edb0c02be2 |
ci: restore the full OBS install, and stop passing a Windows SDK to -A
Two more findings from the three-platform run, both from reading the actual
CI logs rather than guessing.
macOS. libobs now builds, installs, and is FOUND by find_package -- and then
every consumer fails with:
IMPORTED_LOCATION or IMPORTED_IMPLIB not set for imported target
"OBS::libobs" configuration "Release".
Restricting --install to the libobs subdirectory (the previous commit's fix
for the obs-frontend-api install error) also loses the per-configuration
export file, so libobsTargets.cmake lands without its
libobsTargets-release.cmake sibling and the imported target has no location
for any configuration. The install therefore goes back to the whole build
tree, exactly as upstream does, with its exit code tolerated: it gets all the
way through libobs and only then trips over the install rule of a target this
build deliberately skips. If libobs genuinely did not install,
find_package(libobs) in the top-level CMakeLists is where that surfaces, with
a far better message than a half-installed tree.
Belt and braces, the top-level CMakeLists also picks up
obs-plugintemplate's CMAKE_MAP_IMPORTED_CONFIG_* fallbacks, so an imported
target exported under a different configuration name still resolves.
Windows. The sub-configure was re-entering obs-studio's OWN dependency
downloader with a corrupted architecture:
string sub-command JSON member 'hashes windows-x64,version=10.0.26100.0'
not found
Unable to download .../windows-deps-2023-11-03-x64,version=10.0.26100.0.zip
Upstream passes "-A x64,version=<Windows SDK>", and with a current CMake that
",version=" suffix comes back out verbatim in the sub-build's
CMAKE_VS_PLATFORM_NAME -- which obs-studio keys its release assets off. Plain
"-A x64" now. The Windows SDK is selected automatically anyway ("Selecting
Windows SDK version 10.0.26100.0" in the same log), and CMAKE_SYSTEM_VERSION
is passed explicitly.
The macOS job also lists the installed libobs export directory, so the next
run answers "which target files actually landed" from CI output instead of
inference.
Linux remains green and unaffected: ctest 6/6.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
|
||
|
shadowdaoandClaude Sonnet 5
|
f281b4c382 |
ci: keep the synthesised macOS SDK symlink out of the dependency directory
libobs now builds AND installs cleanly on macOS -- libobs.framework, its
headers, and libobsConfig/libobsTargets all land. The configure then fell over
one step later, in the template's own quarantine-clearing step:
xattr: [Errno 13] Permission denied:
'.../.deps/sdk/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk'
`xattr -r -d com.apple.quarantine "${dependencies_dir}"` recurses, so it
followed the SDK symlink into the read-only system SDK. The symlink moves to
the build directory, where that sweep never reaches it. The xattr call itself
also stops being fatal: clearing quarantine on downloaded dependencies is a
convenience, and it should not be able to take the whole configure down.
Separately, in the adapter: the last-frame-geometry marker is cleared whenever
the session leaves Connected, so the next stream logs its first frame again.
Verified in the headless libobs harness by switching the selected camera to a
dark slot and back -- previously the switch back was silent because the
resolution had not changed, so the log stopped answering "did video come
back". It now reads:
connected to ws://... watching cam-test
video frame 640x360 I420
--- switching camera to 'other-cam'
connected to ws://... watching other-cam
--- switching camera back to 'cam-test'
connected to ws://... watching cam-test
video frame 640x360 I420
status after switch-back: connected
which also confirms the whole change-settings path: each switch mints a fresh
obs:<room>:<nonce> identity and reconnects, with no crash and no stale frame.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
|
||
|
shadowdaoandClaude Sonnet 5
|
a910d22870 |
ci: install only libobs from the OBS sub-build
macOS got all the way through this time: the synthesised SDK path satisfied OBS's version check, the sub-build configured, and libobs built and installed -- libobs.framework with its headers, libobsConfig.cmake and libobsTargets.cmake all landed. Then the install failed on the NEXT subproject: file INSTALL cannot find ".../UI/obs-frontend-api/obs-frontend-api.dylib": No such file or directory Installing from the top-level build directory walks every subproject's cmake_install.cmake, and obs-frontend-api is a target this build deliberately never builds -- that is the whole point of dropping Qt. Pointing --install at the libobs subdirectory installs exactly what find_package(libobs) needs and nothing else. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE |
||
|
shadowdaoandClaude Sonnet 5
|
6b12859887 |
Fix assertions that NDEBUG deleted, and match OBS's real macOS SDK regex
test_core.cpp used bare assert(). CI builds Release, Release defines NDEBUG, and NDEBUG compiles assert() out entirely -- so that suite had been passing unconditionally, checking nothing. It now uses the same always-live ST_ASSERT harness as the other suites and reports a count (10 checks), and additionally asserts that core_version() really is the version CMake injected rather than a stale literal. macOS SDK, third iteration. The previous fix assumed OBS only wanted a version-carrying SDK filename. Reading OBS 30.0.2's cmake/macos/compilerconfig.cmake shows the actual pattern is stricter: ".+/MacOSX.platform/Developer/SDKs/MacOSX([0-9]+\.[0-9])+\.sdk$" which only ever matches a full-Xcode SDK path. A Command-Line-Tools-only install keeps its SDK at /Library/Developer/CommandLineTools/SDKs/MacOSX<ver>.sdk, with no MacOSX.platform/Developer/SDKs segment at all, so it can never match however it is named -- which is why the second attempt got past the "REGEX needs at least 5 arguments" error and still landed on "Your macOS SDK version () is too low", with the version still empty. _resolve_versioned_macos_sdk now builds a symlink tree under .deps/ whose shape matches that pattern and which points at exactly the same SDK, and uses the toolchain's own path untouched when it already matches (i.e. when real Xcode is installed). Nothing about the compilation changes -- only the spelling of the path, which is all OBS's check reads. Also refreshes the scaffold-era comments in core.h and core_c.h, which still described this library as a placeholder that would one day talk to livekit-ffi. Linux CI is green on the previous commit: real libobs adapter linked (ldd shows libobs.so.0 plus liblivekit/liblivekit_ffi resolving from the staged package directory), obs_module_load exported, ctest 6/6, artifact uploaded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE |
||
|
shadowdaoandClaude Sonnet 5
|
0fbcb7c2f4 |
ci: give the macOS OBS sub-build a version-carrying SDK path
Second macOS failure, after the Xcode-generator one: OBS's own cmake/macos/compilerconfig.cmake reads the macOS SDK version by regex-matching "MacOSX<major>.<minor>.sdk" out of CMAKE_OSX_SYSROOT, and hard-fails when that does not match -- string sub-command REGEX, mode MATCH needs at least 5 arguments Your macOS SDK version () is too low. The macOS 13.1 SDK (Xcode 14.2) is required to build OBS. -- with an empty version in the message, which is the tell. With upstream's Xcode generator CMAKE_OSX_SYSROOT stays the literal string "macosx" and Xcode resolves it late, so that regex never runs against a real path. With Ninja, which this project now uses because the CI runner has no Xcode, CMake resolves it eagerly to `xcrun --show-sdk-path` -- and on a Command-Line-Tools-only install that is the UNVERSIONED symlink /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk. So swapping the generator moved the failure rather than removing it. _resolve_versioned_macos_sdk now hands the sub-build a path whose filename carries the version: a versioned sibling if the toolchain ships one (the common layout), otherwise a symlink to the same SDK created under .deps/sdk and named MacOSX<major>.<minor>.sdk. Either way clang gets the same SDK; only the spelling of the path changes, which is all OBS's check looks at. Also: the source's worker thread now backs off when the source is unconfigured, instead of re-evaluating once a second forever, and resets the backoff whenever the settings change -- a settings change is an operator action and should retry immediately. Filling the settings in bumps the generation counter and wakes the worker straight away, so the longer backoff costs no responsiveness. Linux re-verified: ctest 6/6. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE |
||
|
shadowdaoandClaude Sonnet 5
|
7146f78831 |
ci: fix the three failures the first real three-platform run exposed
Linux, glibc. The LiveKit SDK's "linux-x64" asset is not actually generic:
it is built on Ubuntu 24.04 and needs GLIBC_2.38 and GLIBCXX_3.4.32, so
linking it on a 22.04 runner fails outright ("undefined reference to
std::ios_base_library_init()@GLIBCXX_3.4.32", "__isoc23_strtol@GLIBC_2.38").
That is exactly what happened when this repo's CI landed on the 22.04 Linux
runner instead of the 24.04 one. LiveKitSDK.cmake now defaults Linux to the
ubuntu-22.04 asset, which needs at most GLIBC_2.35 / GLIBCXX_3.4.30 (checked
with objdump against both archives) and therefore links and runs on 22.04 and
on everything newer -- the right floor for a plugin handed to directors as a
binary.
Linux, libobs version. The Linux job is pinned to ubuntu-24.04 rather than
ubuntu-latest, which this instance's two Linux runners answer with different
releases. 24.04's libobs-dev is 30.0.2 -- exactly the OBS version
buildspec.json pins for macOS/Windows -- so all three platforms build against
the same libobs. A 22.04 runner would have given OBS 27, a different API
surface.
macOS, no Xcode. The OBS sub-build failed its configure with "No
CMAKE_C_COMPILER could be found": the template hardcodes the Xcode generator,
and the `home-mac` runner has the Command Line Tools but no xcodebuild. The
sub-build now uses Ninja (with an explicit CMAKE_BUILD_TYPE, since Ninja is
single-config) and builds a single architecture rather than upstream's forced
universal -- this plugin is single-arch anyway, because client-sdk-cpp ships
single-arch dylibs, so a universal libobs would double the slowest step in CI
for a slice nothing links against.
While in there, generator flags are built as proper CMake lists so each
becomes its own argv entry. Upstream packs several into one space-separated
string and passes it unquoted, which execute_process hands to cmake as a
single argument; it happens not to matter for the optional flags upstream
passes, but it would silently swallow -DCMAKE_BUILD_TYPE.
Also lowers the libobs API floor in the adapter: video_format_get_parameters
instead of video_format_get_parameters_for_format. The _for_format variant
only exists from libobs 30 onwards and only differs for the 10-bit formats
(I010/P010) this source never receives, so using the older entry point keeps
the module loadable on an older OBS -- the direction that matters, since OBS
refuses modules built against a NEWER libobs than the one running.
Re-verified locally on Ubuntu 24.04 with the ubuntu-22.04 SDK asset:
ctest 6/6; the real-LiveKit integration test still reports "36 video frames,
323 audio frames, 10 state changes / 32 checks passed"; and the headless
libobs harness still logs "connected to ws://127.0.0.1:7880 ... watching
cam-test" followed by "video frame 640x360 I420" with the camera dropdown
populated from the live slot list.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
|
||
|
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
|