ci: copy LiveKit runtime DLLs next to Windows test executables
Build / macOS (macos-latest) (push) Successful in 35s
Build / Linux (ubuntu-24.04) (push) Successful in 48s
Build / Windows (windows-latest) (push) Successful in 12m5s

Windows CI now gets through CMake configure/build (the w32-pthreads
bootstrap patch landed), but CTest immediately failed 3/6 suites with
exit 0xc0000135 (STATUS_DLL_NOT_FOUND): test_session,
test_integration_livekit, test_livekit_smoke.

stplugin_core links LiveKit::livekit PUBLICly (core/CMakeLists.txt), so
every test executable under core/tests depends on livekit.dll /
livekit_ffi.dll at runtime. Unlike the $ORIGIN/@loader_path RPATH
handling obs-adapter/CMakeLists.txt already sets up for Linux/macOS,
Windows has no relative-to-the-exe DLL search path -- the DLLs must
physically sit next to the .exe (or be on PATH) when the process starts,
or the loader fails before main() runs. core/tests/CMakeLists.txt had no
equivalent staging step at all.

Added a POST_BUILD copy_if_different in stplugin_add_test(), guarded by
WIN32, that copies the same LIVEKIT_SDK_RUNTIME_LIBS list
(cmake/LiveKitSDK.cmake, already resolves to *.dll on Windows) into
$<TARGET_FILE_DIR:...> for each test binary -- mirroring the pattern
obs-adapter/CMakeLists.txt already uses for its own staged package.
Applied to all six tests rather than only the three known to reference
LiveKit symbols today: harmless for the other three, and avoids
re-diagnosing this if a future test starts touching stplugin_core's
LiveKit-dependent code paths.

Verified locally on Linux (WIN32 branch inert there, but confirms the
rest of the configure/build/test cycle is untouched):
  cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DSTPLUGIN_BOOTSTRAP_OBS=OFF
  cmake --build build
  ctest --test-dir build --output-on-failure   # 6/6 passed

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
This commit is contained in:
2026-09-07 00:57:36 -07:00
co-authored by Claude Sonnet 5
parent a3579d4fd5
commit c4db99414d
+22
View File
@@ -7,6 +7,28 @@ function(stplugin_add_test name)
if(WIN32)
# loopback_server.h needs Winsock for the real-backend tests.
target_link_libraries(${name} PRIVATE ws2_32)
# stplugin_core links LiveKit::livekit PUBLICly (see
# ../CMakeLists.txt), so every test executable here is linked
# against livekit.dll / livekit_ffi.dll. Unlike the RPATH/$ORIGIN
# handling obs-adapter/CMakeLists.txt sets up for Linux/macOS,
# Windows has no way to find a DLL relative to the .exe -- it must
# physically sit next to it (or be on PATH) at process start, or
# the loader fails before main() with STATUS_DLL_NOT_FOUND
# (0xc0000135), which is exactly what CTest saw for test_session,
# test_integration_livekit and test_livekit_smoke. Copy the same
# LIVEKIT_SDK_RUNTIME_LIBS list (from cmake/LiveKitSDK.cmake) that
# obs-adapter stages next to the plugin module, next to each test
# binary instead. Applied to every test here, not just the three
# known to actually reference LiveKit symbols today -- harmless for
# the others and avoids re-diagnosing this if a future test starts
# touching stplugin_core's LiveKit-dependent code paths.
add_custom_command(TARGET ${name} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${LIVEKIT_SDK_RUNTIME_LIBS} "$<TARGET_FILE_DIR:${name}>"
COMMENT "Copying LiveKit runtime DLLs next to ${name}"
VERBATIM
)
endif()
add_test(NAME ${name} COMMAND ${name})
# Nothing here should ever take a minute; a hang is a failure, not a