opencensus-cpp

opencensus-cpp copied to clipboard

Abseil-cpp or other Google project has support on cmake (using add_subdirectory). Is there any plan for opencensus-cpp?

Yes, we would like to support CMake!

Unfortunately, we don't (yet) have a lot of CMake experience; so we would very much appreciate some advice from existing CMake users with regard to how opencensus-cpp's CMakeLists should be laid out. Especially with an eye to how users of opencensus-cpp can consume it via CMake, not just build libopencensus with it.

Use a CMake config. CMake has a few ways to find libraries, but a config makes it easy for the dependencies to get the compiler flags, macro definitions, header files, etc. I've done a bunch of CMake ports and might have some time to help out. Assuming you aren't testing for compiler features etc. it should be fairly straightforward to port.

@isaachier that would be awesome! What I would like to see is the directory https://github.com/census-instrumentation/opencensus-cpp/tree/master/examples/grpc split out into its own repo, with a CMake setup that pulls in opencensus-cpp and gRPC as dependencies and builds everything together.

OK that seems straightforward enough. Just to clarify, do you want opencensus-cpp to have its own CMake build as well (not just the example project)? I have dealt with the gRPC build generator, so I know it is highly configurable in terms of how it locates dependencies (sometimes uses installed libraries, sometimes uses git submodules). Does opencensus-cpp have a preference for where the dependencies are found?

do you want opencensus-cpp to have its own CMake build as well

Yes, absolutely. I'm sorry I wasn't clear on this point.

Does opencensus-cpp have a preference for where the dependencies are found?

I don't know enough about CMake to be able to answer this. What are the best practices around CMake and deps?

We have a similar problem to solve for bazel builds, where the best practice seems to be providing a *.bzl file that helps load dependencies in the outermost project's WORKSPACE file.

Assuming the WORKSPACE file is a good starting point, I think using Hunter would make the most sense. This type of package management is somewhat rare in the C++ world because everyone wants you to be backwards-compatible with the oldest version installed on any device... Yet I highly recommend it.

Right so that is the ultimate question I have dealt with as well. Do you want to maintain compatibility and search for a range of versions already installed on a user's machine? Or do you want to install the dependencies when configuration occurs? WORKSPACE seems to imply the latter.

For the time being, what I'd like is a bazel-like approach where OpenCensus C++ (and also Abseil!) are built into the final RPC server binary, and NOT installed like /usr/local/lib/libabsl.so.1.2.3

I'm not sure what "installing" dependencies means in the CMake world, but I'd definitely like to avoid installing any system-wide shared libraries at this point. That's a separate and much more complicated discussion around ABIs and releasing and packaging that's outside of the scope of issue 86.

Oh definitely not system-wide. Hunter is a tool built on top of an existing CMake feature called add_external_project. Long story short, Hunter maintains a number of library builds in the ~/.hunter directory, but never installs these. If you know how Apache Maven works, I find the scheme very similar.

That sounds good.

The absl & cctz suggest user use them as add_subdirectory https://github.com/abseil/abseil-cpp/blob/master/CMake/README.md. Although the other dependencies in our project managed by add_external_project, I think opencensus-cpp maybe should keep same with absl & cctz. By using add_subdirectory, you can avoid finding libraries. Just add a compile target (like absl & cctz). And also the dependencies of opencensus-cpp can be resolved similarly to absl (it depends on cctz).

Don't worry I'm working on abseil first https://github.com/abseil/abseil-cpp/issues/38#issuecomment-370640039

Does gRPC use add_subdirectory? Is it consumed the same way?

Abseil wants everyone to wait on their cmake decision this week. See post I linked above.

IMO add_subdirectory is an anti pattern nearly as bad as recursive make.

gRPC's CMakeLists use install. But it's heavier than just using its Makefile (for building boringssl). We use a modified version of its Makefile on production with add_external_project. The most problem is if opencensus-cpp want to provide an install target, maybe Abseil should provide one first, or you can't find an Abseil library.

Hi @g-easy, any update on this? A friend of mine tried opencensus_cpp in his own project (not managed by bazel) and failed to build due to the linking deps :( It would be better if we have docs/examples/tutorials on how to use/link opencensus (and its deps) without bazel, especially what .so are required/optional.

No update, sorry. :(

I'm still watching https://github.com/abseil/abseil-cpp/issues/38 to see how abseil resolves this.

The only library required for core OpenCensus functionality (stats and trace) should be abseil. For e.g. Stackdriver exporter, you need gRPC.

Same

Opencensus not supporting CMake is a showstopper for us.

I've made some progress on a prototype of this. Give me a couple of days and I'll roll a PR.

seems like abseil/abseil-cpp#38 will be tracked under abseil/abseil-cpp#111 now.

I have a prototype of a CMake build system. If you're interested in this, please take a look. A good place to start is this out-of-tree example:

git clone -b cmake https://github.com/g-easy/opencensus-cpp-example.git
cd opencensus-cpp-example
cmake -H. -Bbuild
cmake --build build
./build/helloworld/helloworld

The library side of it currently lives on a branch in my repo, which you can browse here: https://github.com/g-easy/opencensus-cpp/tree/cmake -- please leave comments on #238 though. :)