Original title: Private shared library dependencies of exported library now checked at import CMake 3.24 introduced a change that makes libraries in `IMPORTED_LINK_DEPENDENT_LIBRARIES` turn up in the missing files list, which breaks libraries which do not explicitly import these libraries before including the target script. The specific change seems to be this, as the entries ended up in a `dummy` vector before: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7165/diffs#9a5a0b03fa1a219c965f7c368987017dbef214ab_856_848 This lead to issues in OBS Studio because of the following situation: * libobs requires w32-pthreads * Both are built as shared libraries, obs.dll links to w32-pthreads.dll * Both are exported as packages * w32-pthreads ends up in `IMPORTED_LINK_DEPENDENT_LIBRARIES` for libobs. * OBS plugins are loaded at runtime (not linked) and themselves only link to obs.dll * OBS plugins find libobs via its exported package name We had errors in our `libobsConfig.cmake` (one was running `find_package` instead of `find_dependency`) that lead to dependencies being found _after_ importing the target script: * In CMake 3.23 this didn't lead to any issues, as `IMPORTED_LINK_DEPENDENT_LIBRARIES` didn't have any effect. * In CMake 3.24, the value(s) are now added to the target script (`# Make sure the targets which have been exported...`), but because we don't run `find_dependency` before, a `FATAL_ERROR` is emitted. The documentation for `IMPORTED_LINK_DEPENDENT_LIBRARIES` states that it contains values for platforms where linked shared library dependencies are needed at link time (read: Linking to obs.dll requires the linker to be able to resolve w32-pthreads.lib as well, even though the current library does not use any symbols from it). Thus the "new" behaviour seems more correct at first glance, but also leads to sudden breakage on GitHub Actions as GitHub has been rolling out CMake 3.24 on its Windows systems.