CMake install for opentelemetry-cpp-contrib in-tree build was broken

[ThomsonTan]

CMake components were introduced in PR #3220, but since there is no CMake components added for the contrib projects, they cannot be built and installed in tree with opentelemetry-cpp.

[dbarker]

@ThomsonTan Thanks for logging this. Can you share more about the in-tree build approach?

[ThomsonTan]

@dbarker the contrib repo exporters could be included via below cmake line when configured.

opentelemetry-cpp/cmake/opentelemetry-build-external-component.cmake

Line 27 in 9451f0e

add_subdirectory(${DIR} ${PROJECT_BINARY_DIR}/external/${EXTERNAL_EXPORTER_DIR_NAME})

[dbarker]

@dbarker the contrib repo exporters could be included via below cmake line when configured.

Thanks Tom. That helps. I'll look into opentelemetry-build-external-component.cmake. If you have any other context to share on how the contrib repo should integrate with this repo that would also help (ie: is it a goal to create one opentelemetry-cpp installable cmake package from the two repos?).

Currently the common CMake approaches to integrating opentelemetry-cpp into an external project with find_package and FetchContent are expected to work as they have in the past.

#3368 will make it easier to add components with an otel_add_component function. That could support formalizing CMake components in opentelemetry-cpp-contrib if there is interest.

[dbarker]

Looking at #1937 and the discussion on that PR, the intent with the opentelemetry-build-external-component.cmake file is to provide a mechanism to inject a third party extension into the opentelemetry-cpp cmake build to help validate opentelemetry-cpp-contrib against opentelemetry-cpp and to enable building vendor specific extensions easily in one package.

• Validate in future the build compatibility between otel-cpp and otel-cpp-contrib. This change will allow us to add an optional CI job to build otel-cpp-contrib against the otel-cpp repo and thus know right-away if any of main repo change breaks contrib repo.
• Enable building the vendor specific extensions ( e.g., exporters, span-processors, samplers, propagators) as part of otel-cpp build process - This will also allow vendors to creating a single distributable package (deb/rpm/NuGet) containing both SDK + Extension.

To preserve that component injection functionality, and once #3368 is merged, each contrib cmake project would need to add an EXPORT_NAME property to each target intended for packaging and add the targets to an otel component using otel_add_component function. This branch demonstrates how that would look with the geneva metrics exporter. Example here:

set_target_properties(opentelemetry_exporter_geneva_metrics PROPERTIES EXPORT_NAME geneva_metrics_exporter)
...
if(NOT MAIN_PROJECT)
  otel_add_component(
    COMPONENT exporters_geneva_metrics
    TARGETS opentelemetry_exporter_geneva_metrics
    FILES_DIRECTORY include/opentelemetry/exporters/geneva
    FILES_DESTINATION include/opentelemetry/exporters
    FILES_MATCHING PATTERN "*.h")
elseif(OPENTELEMETRY_INSTALL)
...

It is not clear that injecting the contrib components into the opentelemetry-cpp project will be a sustainable approach though. The contrib packages each define their own independent cmake project and install/packaging logic now. There is extra complexity in the contrib project cmake files to support both the injection use case and independent package build use case. The injection use case does not appear to be tested in ci currently.

An alternative to the component injection approach is to use cmake's FetchContent module to add the core opentelemetry-cpp project to the contrib project directly. This is a common cmake pattern and would give the author of the contrib project the ability to build the extension and otel-cpp together while controlling the install/packaging of the targets they need. Then the extra injection logic could be removed.

# Fetch from an existing clone and build
include(FetchContent)
FetchContent_Declare(opentelemetry-cpp SOURCE_DIR "<path/to/opentelemetry-cpp>")
FetchContent_MakeAvailable(opentelemetry-cpp)
...
target_link_libraries(foo PRIVATE opentelemetry-cpp::api)

# Clone and build opentelemetry-cpp from a git tag
include(FetchContent)
FetchContent_Declare(
opentelemetry-cpp
GIT_REPOSITORY https://github.com/open-telemetry/opentelemetry-cpp.git
GIT_TAG        v1.20.0)
FetchContent_MakeAvailable(opentelemetry-cpp)
...
target_link_libraries(foo PRIVATE opentelemetry-cpp::api)

We could also consider creating a single opentelemetry-cpp-contrib cmake project and add the contrib components to it (using FetchContent on opentelemetry-cpp to build/install all as one). This would make it easier to contribute to opentelemetry-cpp-contrib without each component needing to handle the cmake packaging/install logic. This is obviously a bigger change that would need discussion.

@ThomsonTan What do you think?