Drake: Where to add general purpose utility classes in Drake?

[sherm1]

I want to add a generally useful C++ utility class to Drake and I'm wondering where I should put it. I assumed that drake/util would be the place, but after studying that for a while I don't think that's a good choice.

Drake/util currently

• has 234 Matlab .m files, 22 .cpp files (including 9 mex files, which are Matlab wrappers), 16 .h files, and a few subdirectories also mostly populated with .m files.
• generates libraries drakePolynomial, drakeUtil, drakeMexUtil, drakeGeometryUtil, drakeConvexHull and many compiled mex files (binaries currently get put in the source directory)
• contains many namespace-scope utility methods that are actually in the global :: namespace. Many of these duplicate Matlab functions of the same or similar names.

The above makes me think that util is full up with Matlab-related functionality and, despite the name, it is not a place where we should be adding more random utilities.

Instead, drake/core looks much more promising. It currently consists of just three basic C++ headers: Function.h, Vector.h, and Gradient.h, plus one utility that records Drake's source location. There is currently no library produced. I propose that we add basic utilities in drake/core, and add a drakeCore library for non-header code.

Your thoughts, please!

[jwnimmer-tri]

I suggest that we stop using core (e.g., as part of System2 which replaces its concepts). A core is a thing that happens when your program crashes, and it often removed by overly-aggressive build systems or ignored by overly-sensitive IDEs. Nothing under source control should be named core. UNIX has stolen that word forever. Sorry.

One proposal:

• add a new directory base, that precedes core in the drake/drake/CMakeLists.txt (i.e., base is the bottom of the dependency chain);
• eventually we nuke core;
• factor util so that libraries track directory structure identically; either smash it all into one libutil, or move the code into subdirectories, or some mix of the two.

[liangfok]

If the utility classes should ideally be pushed upstream into some other external dependency like the C++ Standard Library, Eigen, or ROS, I recommend putting them into drake/dependency_addons/[name of upstream library]/. This is what I am doing here. It serves two purposes:

1. It physically separates these "improvements" to external libraries from code that's more specific to my library / application / framework / middleware.
2. It serves as a TODO list reminding me to eventually push the add-ons into their respective upstream libraries.

[sherm1]

If the utility classes should ideally be pushed upstream into some other external dependency like the C++ Standard Library, Eigen, or ROS, I recommend putting them into drake/dependency_addons/[name of upstream library]/

That's a nice idea. In the case of Drake's util collection it is hard for me to see a mapping to the external libraries though.

[sherm1]

I suggest that we stop using core ... add a new directory base

:+1:

[liangfok]

Another idea is drake/common since the utility classes will probably be shared among (common to) many other classes.

[david-german-tri]

Honestly, I think util is fine, abundance of MATLAB files notwithstanding. Longer-term we can evolve it in the way @jwnimmer-tri described.

[jwnimmer-tri]

I am happy to see base or common happen. I've used both in the past, and both are good names.

I would prefer _not_ to make the util waste dump any worse. Finding your useful C++ code within a pile of 200+ matlab files is not anyone's idea of a fun time (so +1 to sherm1's OP that we need a different answer).