shadowdaoandClaude Sonnet 5
79de5e8f23
Root cause of the find_package(libobs) failure on Windows: OBS's own modern-CMake Windows layout (obs-studio/cmake/windows/defaults.cmake sets OBS_CMAKE_DESTINATION=cmake) installs libobs's CMake package config to <prefix>/cmake/libobs/ -- a shape find_package(libobs CONFIG) never searches under CMAKE_PREFIX_PATH. Verified empirically with --debug-find-pkg=libobs: CMake's Config-mode search suffixes try <prefix>/cmake/libobsConfig.cmake (no <name> subdirectory) and <prefix>/libobs*/cmake/... (a <name>-prefixed dir first), never <prefix>/cmake/<name>*/. This has nothing to do with the earlier "file INSTALL cannot find obs-frontend-api.dll" error the bootstrap already tolerates -- libobs is the first subdirectory obs-studio's modern top-level CMakeLists.txt adds (well before UI), so libobs's own install(EXPORT ...) rules already completed by the time that later, unrelated install error aborts the script. macOS is unaffected (OBS_CMAKE_DESTINATION=lib/cmake there, matching the standard <prefix>/lib*/cmake/<name>*/ suffix), and so is Linux's libobs-dev (/usr/lib/<arch>/cmake/libobs/, same standard suffix). Fix: point libobs_DIR directly at the from-source Windows install when it exists, bypassing find_package's path-search heuristics entirely. Also fixed a secondary bug found while tracing this: the existing WIN32 locationless-OBS::libobs repair looked for obs.dll under "<deps>/bin" instead of the actual OBS_EXECUTABLE_DESTINATION, "<deps>/bin/64bit". Also make the Windows and macOS "Show what was built" CI steps hard-fail when the OBS adapter module is missing, instead of only printing a message. Several recent "green" Windows runs silently shipped a core-library-only build because of the bug above; nothing in CI caught it, only a human reading the raw log by hand. Left Linux untouched (its check is already a hard, non-"|| true" verification). Applied the same hard-fail treatment to macOS: its bootstrap has been reliably building the real module in CI (6/6 tests, per README), so there's no longer a known legitimate reason for a silent core-only fallback there either -- the documented macOS packaging/bundle-loadability gap is a separate, already-visible issue this check doesn't touch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE