In my current company we\'ve brought the discussion about how to organize most o

Question

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.