Support nlohmann json 2.0.x? #47
Comments
jaeger-cpp defaults to using Hunter to download its dependencies off the 'net,
even if they exist locally. This is convenient for development but not
practical for some production environments. It also makes life hard for clients
that want to link to jaeger-cpp since Hunter doesn't install those
dependencies. It's necessary to also use Hunter in apps that use a jaeger-cpp
built this way... and that's not always practical.
Accordingly, add support for finding jaeger-cpp's dependencies via the normal
CMake package discovery mechanism.
A sligtly unsightly hack is required for nlohmann json, because its header
moved from json.hpp to nlohmann/json.hpp in 2.1.0.
This introduces support for building with
cmake -DHUNTER_ENABLED=0
WIP:
- nothing packages nlohmann json 2.1.0 yet, 2.0.2 is widespread.
but jaegertracing's code doesn't appear to support 2.0.2. For now you
should work around it by installing 2.1.x locally from source.
(jaegertracing#47)
- will fail to compile tests if the local thrift is 0.9.1 since there are
committed generated files from 0.9.2 (jaegertracing#45) and there's no mechanism
to regenerate them.
This seeks to address the beginnings of jaegertracing#38.
Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
|
Interesting. I'm strongly considering another approach for you instead of using system-wide packages. The few I can think of are: wget/curl from archives and submodules. Any reason not to do that instead? |
|
On 29 January 2018 at 02:49, isaachier ***@***.***> wrote:
Interesting. I'm strongly considering another approach for you instead of
using system-wide packages. The few I can think of are: wget/curl from
archives and submodules. Any reason not to do that instead?
Packaging support. Reproducibility. Offline builds. Inclusion in Linux
distros. Stability and predictability. Verifiability - downloading things
means needing a mechanism for validating that they're untampered with,
signature checks, etc.
Many (most) users of PostgreSQL want rpms/debs that've been through a QA
and release process. The PostgreSQL community definitely will not accept
anything that depends on stuff that's so bleeding edge it isn't even on
widespread Linuxes either. I'd be surprised if other open source DBMSes
like MySQL weren't similar in terms of dependencies policies etc.
This looks like a big mismatch of approaches. Presumably jaeger cpp-client
is for fast-moving containerized environments that are highly dynamic and
fetch everything from the 'net. No release processes, etc; grab it from the
'net, try it, seal it and deploy it if it works. That's cool if you're in
the right sort of environment but it's a big problem for things like DBMS
deployments. At linux.conf.au I asked a question in one of the container
talks about how they deal with databases and other data-persistent stateful
services. The answer: oh, we run those outside our container
infrastructure, stateful services are still an evolving thing in the
container world.
I guess it's a question of what the goal of jaeger cpp-client is, the
target audience. Right now I'd argue that its audience is limited to:
- C++11
- Uses containers for everything, minimal local packages etc
- Happy to adopt Hunter in all their applications (and their build systems
can support that)
- Doesn't have to deal with legal and regulatory policies that impose
processes on releases, software sourcing etc
Now, I want to make request lifecycles traceable throughout. From the edge
through caches, proxies, DBMS, etc and back out again.
But that means the build/packaging/deployment model must be able to support
the inner ring services that are slower moving, more conservative, more
stable.
I can work around most of the current dependency issues. But I think I'd
need to know that there was willingness to maintain more conservative
dependencies, at least in terms of not adopting the latest version of
everything as soon as it comes out and keeping in mind what's out there in
the wild. Otherwise I'll be constantly chasing something I can never reach,
and am better off finding a more stability oriented tool. Or writing a C
driver.
So what's your target audience?
…--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|
|
To be honest, the only reason I developed this library the current way is to allow for rapid development. Using Meanwhile, the idea of Jaeger C++ being a library/platform level library does bother me. Especially, considering the use of C++11 in C executables, which no one loves. If we really want a lowest common denominator utility, we should push forward the idea of opentracing-c and follow up with jaeger-c. That library would be painful to develop, but probably much easier to link in with the classic C/C++ development environment, and have much less bloat. My final point, think of Jaeger C++ as a project with a lot of room for improvement. The basic proof of concept is here and it works in production, but compatibility could be extended to other platforms and build systems. I am totally open to hearing about features you'd like, and better yet, seeing pull requests with initial implementations. |
|
Certainly no complaint about Hunter as default. I can see how it's handy for development, for container based work, etc. Though it'd be much, much more useful if you could do something like and get everything Hunter built as well as jaeger-cpp its self. So you can use it from other apps that may in turn not be able to use Hunter. Or where the user doesn't have the time/knowledge to convert the app's build system to use Hunter and just wants to use jaeger-cpp. Big barrier to entry there. (That's what I was getting at with #44) I don't have a huge problem with thunking C++11 into C. It's awkward and annoying, but less so than writing a whole new library and API. Sure, if it massively takes off, that might make sense, but for now just making the C++ lib play a bit better with local installs (and documenting it) would be enough IMO. That's what I've been trying to do here, but am running out of time. I can keep working on it if you're OK with committing to maintaining a degree of lib version compatibility going forward, but otherwise need to drop it here. Definitely no time to write a pure C client. Working on it re doing the work and actually sending pulls. I'm trying to help not just complain. Lots to learn and figure out as I go given I've never met this Hunter tool before - a sort of Maven for C. And that jaeger-cpp hasn't had to care about dependency versions or compatibility so there are lots of unknowns there. |
|
I am willing to agree to that. Good work so far! |
|
@ringerc you've inspired me to begin a minimal client in C. This is a side project so can't guarantee anything about if/when it will be completed. Nonetheless, this might be more along the lines of what you wanted: jaeger-c-client. |
|
@isaachier Cool. I wasn't asking you to, and I've been trying to do what I can to help make the C++ one usable from C. IMO it's OK enough, the problems are related to builds and library management more than language. Thunking from C++ to C is ugly but manageable. |
|
The bigger problem has been Hunter, specific Thrift and json library dependencies not widely packaged, etc. Sure, some folks will whine about C++, and I won't pretend it's a joy to work with in a C project, but that's not where the main challenges have been. |
|
I find C makes tends to be better as a base layer especially when considering language bindings. C99 compiles pretty much anywhere unlike C++11. The C library is more of a challenge for me to implement a bare bones client with as few dependencies as possible. |
|
@isaachier So long as you're happy :) I imagine it'd do good things for adoption if it's easy to plug in, mind. Here are some things I'd be considering, if I were the one doing the work. But since I'm not putting my hand up for that part, feel free to ignore everything I say! I have my hands full trying to get the C++ lib usable for my needs and getting some mergable pulls together for you. Anyway, considerations in a C infrastructure lib:
|
|
If you check out the repo, the alloc.h header allows you to replace the Jaeger allocator. Before joining Uber, used to work at Bloomberg where they rewrote the STL with custom allocators, so I understand the importance of that. Otherwise, all sound like good suggestions I will use going forward. |
|
Thanks. Closing this issue. I've had a look at the changelog between 2.0.2 and 2.1.0 in nlohmann json and it's huge. I have no chance of figuring out what's needed to make jaeger cpp-client work with 2.0.2. There are changes to assignment operators and conversion support, tons of things. I suggest documenting a current required version and sticking to it for a while; the world will catch up. And it's a header-only library so the usual issues with packaging aren't such a concern. |
|
BTW, rewrote the STL o_O ? Seems an odd choice given But gee. I thought PostgreSQL liked wheel reinvention. That's a new level. |
|
Agreed about the plan for libs and will document eventually :/. BSL is a big debate there. Now that you mention it, who do you think was behind that C++11 change to the standard? Bloomberg engineers wrote the proposal: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2554.pdf. Anyway, I didn't use any scoped allocators in the Jaeger code so no issue here. |
Add support for finding jaeger-cpp's dependencies via the normal local
CMake package discovery mechanism of Find modules.
This introduces support for building with
cmake -DHUNTER_ENABLED=0
Limitations:
- Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY,
not newer or older. These versions are not widely packaged
so a local install is necessary. (jaegertracing#45)
- Requires nlohmann json 2.1.0 or newer, which is not widely
packaged in Linux distros. Install a local copy. (jaegertracing#47)
Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Add support for finding jaeger-cpp's dependencies via the normal local CMake package discovery mechanism of Find modules. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Add support for finding jaeger-cpp's dependencies via the normal local CMake package discovery mechanism of Find modules. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Restructure the build system to follow CMake conventions: use import libraries consistently, separate CMakeLists.txt for targets, etc. Add Find packages to discover local dependencies not already supported by CMake natively. These are used when Hunter is disabled to allow jaeger cpp-client to use locally installed libraries. This is a preliminary step in splitting the test sources out of the library. Improves jaegertracing#38 Offline builds This introduces support for building with cmake -DHUNTER_ENABLED=0 Limitations for local dependency builds: - Requires a locally installed Thrift 0.9.2 or 0.9.3 EXACTLY, not newer or older. These versions are not widely packaged so a local install is necessary. (jaegertracing#45) - Requires nlohmann json 2.1.0 or newer, which is not widely packaged in Linux distros. Install a local copy. (jaegertracing#47) Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
Improves jaegertracing#33 Documents jaegertracing#38, jaegertracing#45, jaegertracing#47, jaegertracing#51 Signed-off-by: Craig Ringer <craig@2ndquadrant.com>
I realise everyone loves adding support for old versions of libraries, so this isn't exactly a priority.
But nlohmann json 2.0.x is only currently found "in the wild" on Debian Testing and Unstable. It's not in Fedora 27, which carries 2.0.2, or in Debian stable or AFAICS in backports. Nor in Ubuntu Artful; it'll be in Bionic in April. Certainly not RHEL etc.
The build fails against 2.0.x even once I work around the issue with the header renaming from
json.hpptonlohmann/json.hpp.I just don't have the c++-fu to understand what's going on here. Feel free to ignore if you don't care about compat with older widely deployed libs; that's fair enough.
Error spam:
The text was updated successfully, but these errors were encountered: