In my current company we’ve brought the discussion about how to organize most of our different C++ components considering the following requirements:
- There might be interdependencies between components
- Components with very specific/obscure third party dependencies are not included in this exercise
- Not every project needs every component, just a small subset of them
There are basically two schools of thought (at least within the company) as to how to organize all of the components:
- The first one believes we should group all of the components together in a massive library (which can be composed of more than one shared object and allows linking to what a project needs, but in terms of installation and compilation it’s everything together).
- The second one believes we should create a library per component and maintain them totally separately (each of them installed separately and including as many shared objects as they need).
I can see many cons and pros to both approaches and personally I don’t believe any of them is right or wrong, but I’d like to get a bit more insight from those who have experienced with both approaches and can support with facts the use of one approach over the other.
Edit: being more specific about the concerns.
- How would you manage the version dependencies between a “many small libraries” approach?
- How do you avoid having a mess of interdependencies between objects when having a massive library approach?
- What kinds of performance issues would each approach cause in both windows and linux systems, when statically or dynamically linking? What kinds of benefits?
- Any other comment that could be helpful in deciding what approach to follow?
1
At our company, the dividing line between approach one and approach two comes down to the external dependencies of the component(s). For instance, we have hundreds of “core” components with no dependencies whatsoever, and those are grouped into only a single library. On the other hand, the one component that we use to talk to a specific type of database gets its own library. Similarly, we have a library for our internal service framework, a library for our internal logging framework, and so on, since those libraries depend on the frameworks being installed on the target machines.
1
You should keep an eye on two aspects here:
- The first one is how components you cannot change are already arranged. Third party components or some legacy components you don’t want to change anymore
- Components you or your company wrote, which can be merged or split
One of my Best Practices when deciding how to divide any code in packages is to let the progress itself decide how it would be better for me. That means for example you start a game which will need boost, opengl, openal and opencl. Maybe you’re thinking of a cool engine component loading resources and so on.
You will surely not start with opencl and GPGPU algorithms or audio, so don’t even include opencl/openal in your project at first. You will go that way using boost and opengl to start your project. Then you will might notice that you’re using many filesystem operations at different locations in your code and writing too many strings which are appended for filepaths to load. That would be a nice start of your engine, but still don’t even try to create bunch of files and folders for components you’re not going to implement immediately.
As a conclusion ask every new piece of code if it has a right to exist. Then you’ll see that the question of how to organize your components is no question which should be answered at the beginning of any project, but anytime a further component is used in the project.