Build shared libs, add run-export, register in global pinning

[h-vetinari]

Hey all

I just noticed that arrow comes with an ability to build against opentelemetry, so it would be nice to have this lib ready for that use-case.

AFAICT from the various feedstocks floating around, this is the main one for the CPP lib, but it:

• build static instead of shared libs
• doesn't have a run-export
• is not part of the global pinning

Those things would be the minimum necessary for arrow to build against this feedstock.

[h-vetinari]

@lidavidm, any thoughts on this?

[lidavidm]

Ah, sorry.

All of these should be fixed, but I haven't had a chance to do much other than merge updates for this.

[h-vetinari]

Ok, this was mostly fixed as of #44.

I'd still like to rename the library to something like libopentelemetry according to conda-forge/conda-forge.github.io#1073, rather than have yet another library naming pattern (we can keep the old name as a compat wrapper for a while).

But the opentelemetry stuff is distributed over quite a few feedstocks¹ and I'm not sure if that's conflicting with something else.

Thoughts @lidavidm @wjones127 @xhochy?

Footnotes

1. also notices that the CMake installation files are somewhere in an API package as well and get clobbered (so possibly broken metadata here) ↩

[lidavidm]

renaming is a-ok by me.

the clobbering is an unfortunate aspect of: some things want to just use opentelemetry as a producer/API-only, and don't want to pull in the actual implementation bits, only the headers. But the package itself isn't really designed with that in mind. So we're basically building it twice, and so things get clobbered. I'm not sure how best to deal with this.

[lidavidm]

Maybe upstream would be open to splitting up the package further.

[h-vetinari]

renaming is a-ok by me.

Cool! Do you think we should rename the API output in parallel too? Looking at the open-telemetry org and its repos, we might want to keep the -cpp since there are many different languages.

So perhaps:

• libopentelemetry-cpp & libopentelemetry-cpp-api?

(I'll also note that looking at the content of the package, it's effectively just a header-only package; a similar naming discussion is ongoing for boost currently, where we might use libboost-header-only)

I'm not sure how best to deal with this.

How about not including the CMake metadata in the api package? I opened a PR: conda-forge/cpp-opentelemetry-api-feedstock#17

[lidavidm]

libopentelemetry-cpp/-cpp-api sounds good to me.

The -api scheme is because that's what the package itself calls the header-only variant, not sure which is preferable but I don't mind libopentelemetry-cpp-header-only either.

I think we still want the CMake metadata so that downstream packages can still find_package(OpenTelemetry) and get the headers.

[h-vetinari]

I think we still want the CMake metadata so that downstream packages can still find_package(OpenTelemetry) and get the headers.

I think it would be fine to sacrifice that. Adding another include directory is trivial, whereas CMake metadata contains a lot more metadata than just headers.

[lidavidm]

Right, but then that means projects that depend on opentelemetry will have to adjust builds to work both against the conda-forge package and a 'regular' installation? I'd like to avoid that if possible, though I suppose that's just the nature of dependencies in C++.

[h-vetinari]

Right, but then that means projects that depend on opentelemetry will have to adjust builds to work both against the conda-forge package and a 'regular' installation?

Hm, I tend to "live" in a world where upstream doesn't care about conda-forge (or barely), so to me it's completely fine if upstream continues working only with find_package(OpenTelemetry), and conda-forge deals with the consequences of its packaging decisions.

I just think that clobbering files is a bad packaging smell, not least because we'll constantly spam every user with warnings about that (but also in general).

[xhochy]

I just think that clobbering files is a bad packaging smell, not least because we'll constantly spam every user with warnings about that (but also in general).

I would strongly support removing any clobbering as this can easily cause issues if you start to patch some of the files in only one feedstock and you cannot rely that the patch is correctly installed in the clobbering situation.

[xhochy]

Wouldn't we get around the clobbering problems if this package here depended on libopentelemetry-cpp-api in host and run?

[h-vetinari]

Wouldn't we get around the clobbering problems if this package here depended on libopentelemetry-cpp-api in host and run?

The problem (AFAICT) is that the content of the CMake target files will be different if it's installed as API-only or with the libs. So having it in host would not help.

[lidavidm]

Right, but then that means projects that depend on opentelemetry will have to adjust builds to work both against the conda-forge package and a 'regular' installation?

Hm, I tend to "live" in a world where upstream doesn't care about conda-forge (or barely), so to me it's completely fine if upstream continues working only with find_package(OpenTelemetry), and conda-forge deals with the consequences of its packaging decisions.

I just think that clobbering files is a bad packaging smell, not least because we'll constantly spam every user with warnings about that (but also in general).

Ok! I'll defer to you and Uwe. I'll give the PR a review in a little bit.

[lidavidm]

Merged (and I didn't squash this time!)

[h-vetinari]

Opened a PR for the rename here: #46

After this I think we should be good to add it to the global pinning.