Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CMake find_package for opentelemetry-cpp components #3218

Open
dbarker opened this issue Dec 19, 2024 · 2 comments · May be fixed by #3220
Open

Support CMake find_package for opentelemetry-cpp components #3218

dbarker opened this issue Dec 19, 2024 · 2 comments · May be fixed by #3220
Labels
triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@dbarker
Copy link
Contributor

dbarker commented Dec 19, 2024

TLDR: feature to update the cmake.config file to support find_package(... COMPONENTS ...) and resolve dependencies by component selected.

The opentelemetry-cpp library is nicely configured into components (opentelemetry-cpp::api, sdk,otlp_grpc_exporter, etc.) and provides a clear list of dependencies. The installed opentelemetry-cpp-config.cmake file includes targets for each component but also finds dependencies globally instead of by component.

Problem:
It is not currently possible to use CMake's COMPONENTS argument to find_package to target a specific opentelemetry-cpp component without also having to add find_package statements for dependencies that were included in the installed package. If the installed package was built with gRPC and Protobuf then projects just needing the api or sdk component will also need to add find_package(gRPC) and find_package(Protobuf) to their CMake project.

This seems due to the current config.cmake files use of find_dependency based on the installed configuration independent of components.

Example:
Two simple CMake targets my_library and my_executable in separate CMake projects. The library needs only the otel-cpp api, while the executable needs the sdk and otlp_grpc_exporter.

# `my_library/CMakeLists.txt` 
project(my_library)

# only include the api target and nothing else
find_package(opentelemetry-cpp REQUIRED COMPONENTS api)

add_library(my_library foo.cpp)
target_link_libraries(my_library PRIVATE opentelemetry-cpp::api)
# `my_executable/CMakeLists.txt`
project(my_executable)

# only include the api, sdk, and otlp grpc targets and nothing else
find_package(opentelemetry-cpp REQUIRED COMPONENTS api sdk exporters_otlp_grpc)

add_executable(my_executable main.cpp)
target_link_libraries(my_executable PRIVATE 
    my_library
    opentelemetry-cpp::api 
    opentelemetry-cpp::sdk 
    opentelemetry-cpp::otlp_grpc_exporter
)

This fails currently as you'd need to add find_package(Protobuf ) and find_package(gRPC) to your my_library cmake file even though it does not target the component that brings in the dependency.

Describe the solution you'd like

Update opentelemetry-cpp-config.cmake to call find_dependency conditionally based on the components requested in find_package(... COMPONENTS ...). This ensures that only the necessary dependencies for the requested components are resolved.

Describe alternatives you've considered

There are pkg-config .pc files for a few packages in opentelemetry-cpp (api, common, resources, version, trace, logs, metrics) but not for all components. This isn't a great interface for modern cmake based projects to find packages/components.

# Find pkg-config
find_package(PkgConfig REQUIRED)

pkg_check_modules(OpenTelemetryAPI REQUIRED opentelemetry_api)
pkg_check_modules(OpenTelemetryTraceSDK REQUIRED opentelemetry_trace)

Additional Context

May be related to #3190

@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Dec 19, 2024
@dbarker
Copy link
Contributor Author

dbarker commented Dec 19, 2024

I'm looking into possible implementations and can help. Interested in feedback on the proposal or ideas on possible implementations if this has been considered before.

@dbarker dbarker linked a pull request Dec 23, 2024 that will close this issue
3 tasks
@dbarker
Copy link
Contributor Author

dbarker commented Jan 8, 2025

The workaround to the Protobuf/gRPC transitive dependency issue mentioned in this ticket is to install protobuf independently of gRPC and then build gRPC with the gRPC_PROTOBUF_PROVIDER=package option.

@marcalff marcalff added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants