[CMAKE] Clean up pkg-config install methods and add tests

[shashankxrm]

Fixes #4503

Changes

• Integrate pkg-config generation and installation with the component install machinery.
• Add CMake consumer tests that validate installed pkg-config dependency chains.

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.45%. Comparing base (3dc106f) to head (9241137).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4528      +/-   ##
==========================================
- Coverage   83.46%   83.45%   -0.00%     
==========================================
  Files         521      522       +1     
  Lines       20412    20428      +16     
==========================================
+ Hits        17034    17047      +13     
- Misses       3378     3381       +3     

see 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[owent]

Just windering, would string(GENEX_STRIP "$<TARGET_FILE_BASE_NAME:${_TARGET}>" OPENTELEMETRY_PC_LIBS) be better?

[shashankxrm]

I kept -lopentelemetry_${_short_name} here to preserve the existing pkg-config behavior from before this refactor, where we used -l${target} with target = opentelemetry_${library}.

Using $<TARGET_FILE_BASE_NAME:${_TARGET}> would be more robust if a target ever had a custom OUTPUT_NAME, but in this PR I wanted to avoid changing pkg-config link semantics. Also, since the .pc file is still generated via configure_file(... @ONLY), adopting generator expressions here would need a broader change (likely file(GENERATE ...)) rather than a one-line swap.

I don’t think any otel targets currently diverge from the opentelemetry_<short_name> naming convention, so this should be equivalent for now. Happy to follow up in a separate change if we want OUTPUT_NAME-aware pkg-config generation.

[dbarker]

Thanks for taking this on. I've shared more detail below about the desired end state of #4503 which should include removal of the separate opentelemetry_add_pkgconfig and creation of otel_set_target_properties that sets all the required properties of otel-cpp targets needed for the CMake component and pkgconfig installs.

Given this will be a large scope and touch many files, please reduce the scope of this first PR to only adding the pkgconfig install tests. The first test should verify the installed pkgconfig files by building the test files in install/test/src and cover all of the currently installed pkgconfig files.

[dbarker]

This test currently only covers the pkgconfig files in the ostream component dependency chain. Can it take on a form similar to the current package test to cover all components and pkgconfig files installed?

https://github.com/open-telemetry/opentelemetry-cpp/blob/main/install/test/cmake/package_test/CMakeLists.txt

[dbarker]

My idea with #4503 is to remove the separate opentelemetry_add_pkgconfig, which redefines export name and dependencies of the target. We would then rely on the otel_add_component function to create the pkgconfig files given the targets provided and their properties.

The opentelemetry_add_pkgconfig function then becomes unecessary and the install of the pkgconfig files is a private implementation detail of installing a component.

Current mapping from the opentelemetry_add_pkgconfig args to target properties could be:

• library:
  • Set to the target's EXPORT_NAME property (this seems to be generally the case now but needs to be verified)
• name:
  • To be set to the public facing CMake target alias (i.e: opentelemetry-cpp::api)
• description:
  • To be set from a new target description property
• dependencies:
  • To be set from the target's LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES properties. See _otel_collect_component_dependencies for how this is done now at the component level.

Setting the target properties is still done in many places today (EXPORT_NAME , VERSION, and SOVERSION are separate function calls on each target). These can be consolidated to a function otel_set_target_properties that takes the export name and description.

Looking at the current opentelemetry_metrics target we can already see divergence in the target dependencies between the pkgconfig function and the linked libraries.

Current:

add_library(opentelemetry_metrics ....)

set_target_properties(opentelemetry_metrics PROPERTIES EXPORT_NAME metrics)
set_target_version(opentelemetry_metrics)

target_link_libraries(
  opentelemetry_metrics PUBLIC opentelemetry_common opentelemetry_resources
                               opentelemetry_instrumentation_scope)

target_include_directories(opentelemetry_metrics ...)

if(OTELCPP_INSTALL)
  opentelemetry_add_pkgconfig(
    metrics "OpenTelemetry SDK - Metrics"
    "Components for exporting metrics in the OpenTelemetry SDK."
    "opentelemetry_resources" "opentelemetry_instrumentation_scope")
endif()

otel_add_component(
    sdk
    TARGETS
    opentelemetry_metrics
    ...)

Proposed refactor:

add_library(opentelemetry_metrics)

target_include_directories(opentelemetry_metrics ...)

target_link_libraries(
  opentelemetry_metrics PUBLIC opentelemetry_common opentelemetry_resources
                               opentelemetry_instrumentation_scope)

# Set the target export name and description explicitly. 
# The version/soversion are set implicitly. 
otel_set_target_properties(
    opentelemetry_metrics
    NAME metrics
    DESCRIPTION "OpenTelemetry C++ SDK Metrics Library")

# Set the component name, targets, description, and other existing args. 
# The pkgconfig install for each target will occur implicitly when the component is installed.
otel_add_component(
    sdk
    TARGETS
    opentelemetry_metrics
    DESCRIPTION
    "OpenTelemetry C++ SDK libraries")