new recipe: OpenTelemetry C++ #7799

seemk · 2021-10-22T13:25:25Z

opentelemetry-cpp/1.0.1

OpenTelemetry C++ can be a bit annoying to build due to the amount of dependencies it has, hopefully a Conan package will simplify its adoption.

This package is a requirement for our own distribution/wrapper of OpenTelemetry C++ #7565 (which will get updated once this is merged).

I'm not the author of OpenTelemetry C++ (but have contributed a bit).

I've read the guidelines for contributing.
I've followed the PEP8 style guides for Python code in the recipes.
I've used the latest Conan client version.
I've tried at least one configuration locally with the
conan-center hook activated.

recipes/opentelemetry-cpp/all/conanfile.py

seemk · 2021-10-29T15:13:07Z

@uilianries I know you guys are busy, but we are currently blocked due to this PR (#7565 needs it). Is there anything I can do to speed the process up or ping someone? Thanks 🙂

madebr · 2021-10-30T15:35:02Z

recipes/opentelemetry-cpp/all/conanfile.py

+        if self.settings.os in ("Linux", "FreeBSD"):
+            self.cpp_info.system_libs = ["pthread"]
+
+        self.cpp_info.libs = [


It looks like opentelemetry-cpp installs a lot of libraries, and makes these available as cmake targets (in the opentelemetry-cpp:: namespace).
See https://github.com/open-telemetry/opentelemetry-cpp/search?q=install%28TARGETS
and
https://github.com/open-telemetry/opentelemetry-cpp/blob/af75379971bab0fce4a2338edf5b7efcba9967aa/CMakeLists.txt#L432-L435

Shouldn't this recipe use modules to provide this information?

Could you elaborate?

The library allows its users to only use select libraries.
e.g. only use opentelemetry-cpp::opentelemetry_version instead of needing to link to all libraries provided by opentelementry-cpp.
By using conan modules/components, this information can be provided.

When not providing this information, some dependencies might fail to build when these targets are not available.

(perhaps opentelemetry_cpp is a wrong example, but the reason holds for all other libraries)

It does, although using one lib of it is quite useless. I don't think anyone would do it with Otel C++. Don't really know why they split it up like that.

@madebr e.g. see this section: https://github.com/open-telemetry/opentelemetry-cpp/blob/main/INSTALL.md#incorporating-into-an-existing-cmake-project

I'm kinda lost at package_info at how to achieve it, if the target name for find_package is opentelemetry-cpp, how can I also make Conan (1.42) export OPENTELEMETRY_CPP_INCLUDE_DIRS and OPENTELEMETRY_CPP_LIBRARIES?

The easiest way to achieve this is to create a .cmake file in the package method that sets these cmake variables, using the target(s) created by cmake_find_package.
Something like

tools.save(os.path.join(self.package_folder, self._module_file_rel_path), textwrap.dedent("""\ set(OPENTELEMETRY_CPP_INCLUDE_DIRS ) set(OPENTELEMETRY_CPP_LIBRARIES opentelemetry-cpp::opentelemetry-cpp) """))

And make sure to add self._module_file_rel_path to build_modules and self._module_subfolder to builddirs.

I suggest grepping for some names in the cci repo for examples on how other recipes do this.

@madebr the splunk-opentelemetry PR will get updated after this one, find_package works with opentelemetry-cpp_LIBRARIES, but how can I get it to export OPENTELEMETRY_CPP_LIBRARIES while keeping the package name (for find_package) opentelemetry-cpp?

See #7799 (comment)
Write a custom .cmake script to the package folder in the package method + add the dir to builddirs + add the cmake script to build_modules.
See the docs + other recipes.

Check e.g. the openssl/3.0 and xapian-core recipes on how this can be done.

@madebr Thanks for the help, I've changed the recipe to use components and added a variables file.

conan-center-bot · 2021-11-02T22:43:18Z

All green in build 30 (527710b5aabf7b9343526dc692e8fb8056283f91):

opentelemetry-cpp/1.0.1@:
All packages built successfully! (All logs)

seemk · 2021-11-02T22:45:20Z

Had to retrigger CI due to stuck CLA check

MathiasDanzeisen · 2021-11-03T17:53:34Z

recipes/opentelemetry-cpp/all/conanfile.py

+    _cmake = None
+
+    def validate(self):
+        if self.settings.arch != "x86_64":


What would be needed to provided this for armv8 as well?

Per OpenTelemetry C++ docs only x86-64 is officially supported (and CMake is not officially supported on MacOS): https://github.com/open-telemetry/opentelemetry-cpp#supported-development-platforms

I think it would need to be tested, but that would entail work in OTel C++, so perhaps it might be lifted in newer versions.

seemk · 2021-11-03T18:42:22Z

Had to retrigger CI due to stuck CLA check

@madebr This invalidated your approval, sorry! 👀

recipes/opentelemetry-cpp/all/test_package/CMakeLists.txt

uilianries

LGTM

* add opentelemetry-cpp * debug m1 arm cmake config error * only support x86_64 for now * quote protos path * replace backslashes in protos path * support VS2019 and up * attempt removing absl directory amiguity * fix pep * enable short_paths * enable fPIC by default * disable fPIC option on Windows * remove debug replace * use cmake_find_package_multi, remove unused import * use cmake_find_package_multi for the test package * support shared libraries, add pthread as a system lib on linux and freebsd * removed shared option * reattempt shared libs with a modified opentelemetry_proto cmake * remove shared lib settings * enable shared libs, disable on macos * only allow shared lib on Linux * export all symbols on Windows * increase required cmake version * include ws2_32 syslib on windows * disable shared libs on everything except Linux * remove fPIC on Windows * move source patching to a function, remove comment * add cmake variables, use components * remove the need for patching * remove cxx standard from test_package cmake * readd test_package cxx standard

add opentelemetry-cpp

1c022d2

prince-chrismc mentioned this pull request Oct 22, 2021

Pull Requests Ready to be Reviewed prince-chrismc/conan-center-index-pending-review#1

Open