I’m developing a C++ software, which is going to read and write ROOT files. Because my program will be distributed across multiple platforms, I carefully weigh every library dependency that I introduce into my build chain. For this reason, I’m not too excited about linking against the entire ROOT framework just to be able to read/write files.
My question is: since besides files and trees, I technically do not need any of the advanced analysis, plotting and fitting features of ROOT, is there a possibility to minimize the footprint of ROOT in my software? Can I just link against a small self-contained subset of ROOT without making my software heavy? If so, can I link ROOT statically into my program, so that I do not have to worry about whether my users have the correct ROOT version installed?
Alternatively, I found projects like UpROOT that bring native support for ROOT I/O to Python. Do you know if there exists something like UpROOT but for C++?
Many thanks for any advice you can provide.
Best, Petr
You could probably compile ROOT activating the option minimal when calling CMake. You’ll only need then libRIO, libCore and libThread. Building ROOT from source - ROOT
You could probably compile ROOT activating the option minimal when calling CMake.
I just tried it locally with the latest stable version. The difference is about 3K compilation steps (7K with minimal, 10K with default options). Would this be consistent with your expectations? …or am I doing something wrong?
So, I tried turning builtin_clang and builtin_llvm off. Unfortunately on my bleeding-edge Linux distribution, ROOT complains that my installed versions of llvm and clang are too new (I have llvm v17, ROOT prefers v13). When I have time, I will repeat this test in my continuous integration, which is running the oldest Linux we support (Ubuntu Focal), and report back.
In the meantime, let me return to one question I asked earlier: is it possible to link with ROOT statically (provided that -fPIC is enabled, of course)?
you could also use C-bindings to groot (IIRC, that’s what Julia is doing for xrootd: they are generating C-bindings to Go-HEP’s package xrootd (at least, that’s what they were doing at some point…)
Go is building assets statically by default (and has a great story for cross-compiling pure-Go projects. groot is such a thing)
I see. I think I will not be using that, then. I think we have successfully managed to narrow my use case down to linking dynamically with just libRIO, libCore and libThread to get the I/O part working. I will try my best to use distribution-provided ROOT package, but if unavailable (vcpkg, I am looking at you) I will have to integrate ROOT as a submodule and include it with -Dminimal=ON in my CMake project.
One more follow-up question: is there a way to explicitly disable ROOT’s global state objects (gStyle, gDirectory etc.) and signal handlers (I am using my own crash handling system)? If I move forward with integrating ROOT in my program, I would really like it to have as small memory footprint as possible.
you could also use C-bindings to groot
Interesting suggestion, I will have to investigate that. Naïvely, going from C++ to Go and back to C/C++ seems like an interoperability nightmare. However, I will try to whip up a small demo to see if this would bring any value to my project.
a colleague of mine did something along these lines (they weren’t wrapping groot, but fmom, although, from the point of view of the mechanics of wrapping Go code, it’s kind of the same):
Naïvely, going from C++ to Go and back to C/C++ seems like an interoperability nightmare
Note that groot isn’t calling into C/C++, it’s a reimplementation of (a subset of) ROOT in pure-Go.
so you’d “just” call [C++ → C-shim → Go]. (you still don’t want to do that in a very tight loop, though.)