My C++ project is growing larger. We are also moving to using cmake for building now. I want to divide the application into libraries so that they can be linked for testing, preparing the application package, etc. Right now I would divide my code into libraries as follows:
- core
- GUI
- utilities (these are used by core and other components)
- io (xml parsing/outputing using print functions of classes in core)
- tests (unit tests)
- simulator (tests the core)
An alternative would be to divide based on the directory structure – one library for each directory. But from my past experience it leads to too many libraries and then library dependencies become tough to handle during linking.
Are there any best practices in this regard?
Sit down with a piece of paper and decide your library architecture.
The library should be designed as a set of levels.
Each library should represent a complete job at its particular level. Things at lower level generally have smaller jobs but lots of them. A library at a higher level should reresent a complete task. ie don’t have a lib for windows objects and a lib for events. At this level the job here is handline all interaction with a window (this includes how it interacts with events).
You seem to have identified some resonable functional groups. The only one that see a bit suspicious is io. If you truly have some generic IO routines that provide real functionality fine. But if it is just grouping the IO for a bunch of different objects then I would scrap that (it all depends on the usage).
So the next step is to identify the relationship between them.
As for using directory structures. Usually everything in one directory will be present within the same library, but that does not exclude the posability of other directories also being present. I would avoid putting half the classes in directory in libA and the other half of the classes in libB etc.