Build Subsets Of Ocean

[robo-todd]

🚀 Feature

The build scripts are very helpful for getting started, but the dependency closure of all of ocean is very large and includes libraries we would not want to have on an embedded system. Can there be a way provided to enumerate which components of ocean to include in the build process, or perhaps just instructions on building subsets of ocean?

Motivation & Examples

Ocean already is broken down into a clean, conceptual set of component libraries but the build process (and most importantly the third party dependency build process) currently assumes you want to use "everything". I have a project where we would never be using any graphics / X11, etc. related code, nor any networking or HTTP code, etc. form the library. We would be using it as a vision processing library only and our target environments don't always have all dependencies.

Is there a way to provide modular build support at the level of build scripts, etc. or perhaps just alternative build instructions so that we don't have to reverse engineer the build process for the library?

Would you be able/willing to contribute to this work? Yes.

[ASchneiderMeta]

It would be pretty straightforward to add some gating logic in the CMake configuration to prevent building components of ocean that are dependency-heavy. There would be a CMake option exposed to the user, e.g. OCEAN_DISABLE_OPENGLES, which could be asserted either by editing a CMakeLists.txt or on the command line. Would that provide most of what you're looking for? If so, which dependencies are you most interested in being free from?
We can also gate the building of third-party dependencies (before ocean is built). The build_thirdparty_* and build_ocean_* processes aren't very tightly coupled, so there would be a burden on you, at least at first, to make sure the two sets of gates are in sync.

[robo-todd]

Supporting some sort of CMake configuration gating would be exactly what I am looking for. It is pretty common in other OSS projects to allow them to be used with/without GUI integration, with/without Python wrappers being included and so forth.

Picking a compatible set of options for thirdparty + ocean is a reasonable burden (I think at least) for a customized build. The premise would be that you know what you're getting into if you are customizing the build at that level.

I'm reading through the libraries and it seems like there are some areas with this would be straightforward and other areas that will be problematic.

These ocean component libraries (for us) seem to be a coherent core vision/math foundation with a small dependency closure:

• ocean/base
• ocean/cv
• ocean/math
• ocean/geometry
• ocean/tracking
• ocean/io - Assuming it does not actually implement graphical drawing for its 'map rendering' feature?

These ocean component libraries (for us) seem like modular 'extras' that we would like to be able to turn off (including the induced 3rd party dependencies for them):

• ocean/rendering
• ocean/interaction
• ocean/network
• ocean/platform (but some pieces in here are mixed, right? We still need some of them I think?)
• ocean/scenedescription
• ocean/devices

Lastly, there are almost certainly some cases where we wish we could get various sub-pieces of a component library. For example ocean/media seems like an area where we would want some things but not others and I'm not sure how fine-grained a practical solution should be.

[robo-todd]

I would add that specifically we would love to avoid extra dependencies on:

• gl
• curl
• freetype
• assimp
• libusb
• mbedtls

And then minimize the build to avoid areas we don't directly need being built.

Lastly, since we're going over it:

It would be amazing if it could use a specific Eigen installation as an incoming dependency rather than building its own Eigen. We would like to avoid ending up with many different builds/versions of Eigen in a single process. Just seems like that will cause trouble eventually.

[ASchneiderMeta]

Great food for thought! It's very helpful to know more specifically what you're looking for. We'll dig in and get back to you soon.