SPDLOG_INSTALL ON

[stephen-derosa]

Building against release 0.3.2 causes error:

-- [download 99% complete]
-- [download 100% complete]
-- LiveKitSDK: extracting /home/runner/work/cpp-example-collection/cpp-example-collection/build/_downloads/livekit-sdk-linux-x64-0.3.2.tar.gz
-- LiveKitSDK: using SDK at /home/runner/work/cpp-example-collection/cpp-example-collection/build/_deps/livekit-sdk/livekit-sdk-linux-x64-0.3.2
CMake Error at /usr/local/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76 (find_package):
  By not providing "Findspdlog.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "spdlog", but
  CMake did not find one.

  Could not find a package configuration file provided by "spdlog" with any
  of the following names:

    spdlogConfig.cmake
    spdlog-config.cmake

  Add the installation prefix of "spdlog" to CMAKE_PREFIX_PATH or set
  "spdlog_DIR" to a directory containing one of the above files.  If "spdlog"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  build/_deps/livekit-sdk/livekit-sdk-linux-x64-0.3.2/lib/cmake/LiveKit/LiveKitConfig.cmake:28 (find_dependency)
  CMakeLists.txt:38 (find_package)


-- Configuring incomplete, errors occurred!

This MR adds a build against an external project in CI to test cmake linking. It depends on this work

I brought in the github action client build commit into this MR to include the test of the fix!

[Copilot]

Pull request overview

This PR changes the CMake configuration for the vendored spdlog dependency so that spdlog’s own install rules are enabled when fetched via FetchContent on macOS/Linux.

Changes:

• Enable SPDLOG_INSTALL for the vendored spdlog build (OFF → ON).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Setting SPDLOG_INSTALL to ON will make the vendored spdlog subproject participate in the parent install step (installing its headers/CMake package). This can be surprising when LiveKit is consumed via add_subdirectory and can also reintroduce the kind of subproject install/export issues you explicitly disabled for vendored protobuf/abseil (cmake/protobuf.cmake notes this to avoid export-set errors). Consider gating this with LIVEKIT_IS_TOPLEVEL (or introducing a LIVEKIT_INSTALL_DEPS option) so dependency installs only happen for the standalone SDK bundle use case.

Suggested change

	set(SPDLOG_INSTALL ON CACHE BOOL "" FORCE)
	if(LIVEKIT_IS_TOPLEVEL)
	# When building LiveKit as the top-level project, allow vendored spdlog to install
	set(SPDLOG_INSTALL ON CACHE BOOL "" FORCE)
	else()
	# When LiveKit is consumed as a subproject, avoid installing vendored spdlog
	set(SPDLOG_INSTALL OFF CACHE BOOL "" FORCE)
	endif()

[stephen-derosa]

I had been of the thought that we should package spdlog with our SW to enable our logging macros (very useful) out of the box. But do we think we should require applications to explicitly install and link their app against us + spdlog? curious on your experience here @xianshijing-lk