tesseract without dependency to boost

[deaswdev]

I like tesseract-robotics, as it is light weight and limits the number of external dependencies.

But dependency to "boost" results in dependency to ~70 boost libraries, because of inner dependencies. (when my analysis was correct)

In my industry field, we have to analyse on each release all open issues of all used open source libraries regarding influence on desired functionality. This would mean to check all 70 boost libraries on each release, if they have new open issues and evaluate influence on functionality!

Would it be possible to remove the dependency to boost from tesseract core or at least make it optional?

I already analyzed the tesseract code and see the following three boost dependencies as most critical to remove:

• boost_graph: used in scene_graph: Maybe other graph library with less dependencies can be used?
• boost_dll: for plugin loader, maybe implement it without external dependency, as ros2 does it in rcutils/shared_library
• serialization: maybe just create mock to make it optionally

What do you think about it?

[Levi-Armstrong]

I am in favor of this and I have looked at this multiple times, but for myself it seems like an overwhelming task that I cannot take on personally. If someone or company is interested in such a task I would personally support this endeavor and help with the development.

• boost_graph, I think this could be replaced with existing light weight by copying into tesseract. I have looked at several header only along with possibly copying the implementation form Ignition/Gazebo.
• boost_dll: We have broken out this code to a stand alone repository called boost plugin loader but it still depends on boost. I would recommend starting with that repo and replacing the boost components. Once boost is removed we could rename the repository. It is on the roadmap to update tesseract to leverage this repo.
• serialization: I think this is the largest hurdle to overcome, but possible making it optional would be a good start.

[deaswdev]

I will create fork and try to create first prototype of tesseract without boost, if I find some time in the next weeks.

For boost graph replacement, I need your advice/help, because i am not yet really expert in scene graph implementation, neither in boost_graph. What features from a graph framework do we really need in tesseract? Do we really need comprehensive graph solution, then maybe also CXXGraph could be alternative. Otherwise, we can just try to use light weight solution based std:: collections, e.g. Adjacency List (using std::unordered_map and std::vector).

For boost_dll (plugin loader), I would try to integrate "shared_library" code from ROS2 rcutils package (with removed ROS dependencies). As this is OSRF Apache 2.0 licensed, this should be OK?

For serialization my idea is to create stub library for boost serialization, which satisfies the dependencies from tesseract code, but basically does nothing, so that we do not need to change tesseract classes itself

For the rest, like boost_filesystem or algorithms, I would adapt tesseract code to alternative solution, e.g. use std::filesystem.

[Levi-Armstrong]

boost_graph: Currently we leverage a bi-directional graph along with the following algorithms. BreathFirst, DepthFirst and Dijkstra.

• https://github.com/gazebosim/gz-math/tree/gz-math8/include/gz/math/graph
• https://github.com/bobluppes/graaf
• https://github.com/fhamonic/melon

@marip8 What are your thoughts on how to replace boost graph?

[Levi-Armstrong]

Maybe this is a good option for options. https://github.com/jarro2783/cxxopts

[Levi-Armstrong]

Also probably a good replacement for boost uuid by just copying it into tesseract_common.
https://github.com/mariusbancila/stduuid/blob/master/include/uuid.h

[marip8]

I have mixed feelings on replacing boost generally. Is there really a benefit to replacing one external dependency with another? At least boost has been around for a long time, has wide usage/good documentation, and been thoroughly tested, whereas these other libraries maybe don't have the same "heritage". Reimplenting these algorithms ourselves (or copy-pasting solutions from other repositories) also adds a lot of additional code and maintenance/testing burden.

Why not just copy-paste the elements of boost that we're using into Tesseract (or pin to a specific version of boost with a git module)? Then API doesn't need to change and you effectively cut out the dependency on boost without sacrificing its benefits (e.g., testing, examples, documentation, community, etc.)

[johnwason]

The vcpkg actions in the github workflows install a minimal set of boost packages. The overhead is pretty small.

[deaswdev]

I agree that boost is stable and widely used open source framework and also has liberal license for commercial use. Disadvantage in my opinion is inner dependency tree in boost, using one lib results in dependency to 10 other boost packages, which itself have dependencies to others and so on.

When my analysis was correct, used boost libs in tesseract result in about 70 boost packages, because of inner dependencies to other boost packages. Do you have here other number?

And even pinning boost to fix version, would not solve my issue. In our industrial domain, I would still have the obligation to check and evaluate on each SW release, whether there are new known issues in these 70 boost repos, which can influence the functionality of my SW.

I also agree, that replacing boost, with a number of other open source libs, which are less community proven, is also not a good idea. I will analyze it in more detail and will share a proposal

[johnwason]

One other thing to consider about boost vs other libraries, is that there is a lot more reuse of code within boost. Other single-function libraries still need these functionality provided by these reusable components, and probably have their own implementation, or copied it from somewhere else. My experience is that it is far better to use the common code that has a lot more users. Because of the limitations of the C++ standard library (which have been improving), boost has filled this role.