shadowdaoandClaude Sonnet 5
6b12859887
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
40 lines
1.7 KiB
CMake
40 lines
1.7 KiB
CMake
# Dependency-free CTest targets (see test_util.h for why there is no gtest).
|
|
|
|
function(stplugin_add_test name)
|
|
add_executable(${name} ${name}.cpp)
|
|
target_link_libraries(${name} PRIVATE stplugin_core)
|
|
target_include_directories(${name} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
|
|
if(WIN32)
|
|
# loopback_server.h needs Winsock for the real-backend tests.
|
|
target_link_libraries(${name} PRIVATE ws2_32)
|
|
endif()
|
|
add_test(NAME ${name} COMMAND ${name})
|
|
# Nothing here should ever take a minute; a hang is a failure, not a
|
|
# reason for CI to sit for its default 1500s.
|
|
set_tests_properties(${name} PROPERTIES TIMEOUT 120)
|
|
endfunction()
|
|
|
|
stplugin_add_test(test_core)
|
|
target_compile_definitions(test_core PRIVATE
|
|
STPLUGIN_EXPECTED_CORE_VERSION="${PROJECT_VERSION}"
|
|
)
|
|
stplugin_add_test(test_json)
|
|
stplugin_add_test(test_api_client)
|
|
stplugin_add_test(test_session)
|
|
|
|
# End-to-end against a REAL LiveKit room: publishes a synthetic camera with
|
|
# the same SDK and subscribes to it through LiveKitSession. Skips (exit 0)
|
|
# unless STPLUGIN_IT_* is set, so the three build runners -- which have no
|
|
# LiveKit server -- stay green. See scripts/livekit-dev-room.py.
|
|
stplugin_add_test(test_integration_livekit)
|
|
set_tests_properties(test_integration_livekit PROPERTIES TIMEOUT 300)
|
|
|
|
# Smoke test for the LiveKit SDK link: initialize()/shutdown() must succeed
|
|
# in-process. This is the cheapest possible proof that LiveKit::livekit is
|
|
# not just linked but loadable and callable (it dlopen-chains into
|
|
# liblivekit_ffi, which is where a broken RPATH would show up).
|
|
stplugin_add_test(test_livekit_smoke)
|
|
target_compile_definitions(test_livekit_smoke PRIVATE
|
|
STPLUGIN_EXPECTED_LIVEKIT_VERSION="${LIVEKIT_SDK_VERSION_RESOLVED}"
|
|
)
|