Any plan for cmake supporting?

[fancl20]

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

[g-easy]

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.

[isaachier]

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.

[g-easy]

@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.

[isaachier]

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?

[g-easy]

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.

[isaachier]

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.

[isaachier]

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.

[g-easy]

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.

[isaachier]

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.

[g-easy]

That sounds good.

[fancl20]

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).

[isaachier]

Don't worry I'm working on abseil first abseil/abseil-cpp#38 (comment)

[g-easy]

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

[isaachier]

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

[isaachier]

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

[fancl20]

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.

[HailongWen]

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.

[g-easy]

No update, sorry. :(

I'm still watching abseil/abseil-cpp#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.

[isaachier]

Same

[greuff]

Opencensus not supporting CMake is a showstopper for us.

[g-easy]

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

[StevenYCChou]

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

[g-easy]

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. :)