If external nlohmann::json is not found, then use one from our submodule

[maxgolov]

Fixes #843 ( partially 😄 )

Quick recap: despite the fact that we clone nlohmann::json library as one of our submodules, we do not attempt to use that by default. Neither in Linux nor in Windows. This is a bit illogical, because for Windows - we expect it to be provided by vcpkg, on Mac we install it with brew, and on Ubuntu we expect it to be installed via apt... Despite the fact that we actually have it right there - in the submodule!

Changes

The following components depend on / require nlohmann/json.hpp :

• ETW exporter (optional for MsgPack binary payload encoding)
• OTLP HTTP exporter
• Elastic logs exporter
• Zipkin exporter
• w3c Trace Context tests
• zPages

Given that:

• in majority of scenarios the library is required.
• and the library is (header-only) always there - one of our submodules.

I'd like to consolidate the usage of it as follows:

• stop requiring it in all these modules above
• and instead require it unconditionally once in top-level CMakeLists.txt
• try to find nlohmann_json package (e.g. installed via brew or vcpkg) first
• if the package is not found, then use our local submodule snapshot (that's always there and will always be found)

The library itself is "pay-per-play". It's header only. If someone builds a build combo without it, - fine, we're good, we're just not including it. We require it. But we don't include it. This approach makes the overall SDK build / consumption experience much smoother.. And we no longer need to explain why we have JSON right there in the submodule but it's not found during the build. Making this world quite a bit more sane and reasonable place.

Note that we presently don't install / export / deploy the json.hpp library together with OpenTelemetry SDK headers. The library remains private in most cases. If we ever need to export that as part of OpenTelemetry SDK, i.e. install it to user include directories, then we could set the JSON_Install option to ON. This installs our local snapshot of nlohmann/json.hpp.. But in cases where users really feel like their code depends on json.hpp, they might as well install their own version themselves via pkg manager.

Similar approach could be implemented for benchmark, googletest and ms-gsl... But for for now I'm tackling this only for nlohmann/json.hpp.

[codecov]

Codecov Report

Merging #865 (dcbf2b5) into main (4947ab7) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #865      +/-   ##
==========================================
+ Coverage   95.49%   95.50%   +0.02%     
==========================================
  Files         156      156              
  Lines        6620     6620              
==========================================
+ Hits         6321     6322       +1     
+ Misses        299      298       -1     

Impacted Files	Coverage Δ
...include/opentelemetry/sdk/common/circular_buffer.h	100.00% <0.00%> (+2.09%)	⬆️

[lalitb]

Will it fail cmake configure if submodules are not checked out? Just thinking of the scenarios if the user wants to build api and sdk which ideally doesn't have json/curl requirements, we shouldn't let configure fail in those cases.

[maxgolov]

Since it is required for most build configurations (certainly required for default build configuration), I can add a check if directory exists to alleviate your concern. If it does not exist, I can trigger a warning recommending to do recursive cloning or installing nlohmann_json package manually? I think in most documents we do recommend cloning recursively. Certainly for Windows we do recommend it here

[lalitb]

Yes agreed. How about not failing the cmake configure if WITH_API_ONLY is enabled and json is not installed? Though I don't have strong opinion on this :)

[maxgolov]

@lalitb - Sounds good. I can improve it in one of my other build infra PRs!