build: make cloudini_lib embeddable with add_subdirectory / FetchContent

[facontidavide]

Summary

Makes cloudini_lib safe to embed with add_subdirectory() / FetchContent. Found while embedding it in pj_bridge, which currently needs ~45 lines of workarounds; against this branch that block shrinks to:

FetchContent_Declare(cloudini URL ... SOURCE_SUBDIR cloudini_lib)
set(CLOUDINI_FORCE_VENDORED_DEPS OFF CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(cloudini)
target_link_libraries(my_target PRIVATE cloudini::cloudini_lib)

(verified locally: pj_bridge builds against this branch with exactly that, 303 tests pass, static link, nothing of Cloudini installed, parent build type untouched).

What leaked into the parent, and the fix

Each item was reproduced first with the new consumer project cloudini_lib/test/subproject, which embeds the library like a parent would and fails at configure time if something leaks. It now runs in the Ubuntu CI job.

Problem when embedded	Fix
find_package(zstd CONFIG) fails with "Some (but not all) targets in this export set were already defined" when the parent already defined zstd::libzstd_shared (e.g. from a Find module)	zstd and lz4 lookups reuse existing targets instead of looking the package up again
In a ROS parent, the inherited ament_cmake_FOUND turned the embedded library into a SHARED ament package with its own ament_package()	ament is only considered when Cloudini is the top-level project
CMAKE_BUILD_TYPE=Release forced into the parent's cache; include(CTest) defined BUILD_TESTING there	top-level only
Tests, tools, benchmarks, PCL and install rules on by default; PCL became a PUBLIC link dependency of the parent	defaults follow "is top-level"; new options CLOUDINI_WITH_PCL and CLOUDINI_INSTALL
data_path.hpp written to the parent's ${CMAKE_BINARY_DIR}/include, colliding with a parent file of the same name	${CMAKE_CURRENT_BINARY_DIR}/include
cloudini::cloudini_lib only existed after install	alias always defined, so consumers use one name for installed and embedded builds

Top-level detection uses CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR because PROJECT_IS_TOP_LEVEL needs CMake 3.21 and the project supports 3.16.

Also fixed: missing Threads dependency

PointcloudEncoder uses std::thread, but cloudini_lib did not link Threads::Threads. A static consumer on an older glibc (conda sysroot) failed with undefined reference to pthread_create — the new consumer test caught this in a RoboStack environment. Now linked PUBLIC, with find_dependency(Threads) in the package config and ament_export_dependencies(... Threads).

Top-level behaviour is unchanged — verified

• standalone: defaults to Release, tools built, 26/26 tests, cmake --install produces the same package files, and a find_package(cloudini_lib) consumer links against the installed static library
• ament/colcon (RoboStack Humble): still builds libcloudini_lib.so and exports its targets
• embedded: plain Ubuntu and RoboStack Humble, configure + build + run + install (only the parent's own binary is installed)

Version 1.3.1

The version is set to 1.3.1 everywhere it is declared: project(cloudini_lib VERSION ...) (it was still 1.2.4 in the 1.3.0 release, so find_package(cloudini_lib 1.3) failed against a 1.3.0 install), both package.xml files, conda/recipe.yaml, and a 1.3.1 section in both changelogs. This branch also contains a merge of main (#141).

After tagging 1.3.1: refresh sha256 in conda/recipe.yaml — it is still the 1.2.4 tarball's hash and is marked STALE (CI is unaffected, it builds the recipe from the checkout). cloudini_foxglove/package.json (1.2.2) is versioned separately and was left alone.

Not changed

The ament install still exports cloudini_lib::cloudini_lib while the standalone install exports cloudini::cloudini_lib; unifying them would break cloudini_ros, so it is not part of this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01711BZcEtp3KsoF9uZHNFME