F1CM's codebase is one huge monolithic C++ solution/project. Currently weighs in at around 30,000 lines over ~100 files. Thats just the framework - once I drop the game on top it'll probably triple or quadruple in size.
Monolithic project works fine for me as the single developer/owner. Not so great when we're looking to get multiple developers involved. Yeah, bad design on my part [embarrass].
I want to break the solution up into seperate components. Obvious advantages really:
- Reduced compile time
- Stabilise components seperately
- Easier concurrent development - less chance of multiple developers breaking each others stuff
- More manageable (both from usage and error point of view)
Thing is, I'm not sure what the best route is to achieve this.
I dont really want to change too much of the architecture if I can avoid it. It's too late in the project for that now - even if it is a hacked up cringe-worthy job that'll be fine.
From preliminary research I have two choices: Static or Dynamic Libraries.
I could rip out the Graphics/Audio/Log/Logic/GUI/Kernel stuff into seperate components. They're already fairly well compartmentalised (sadly, with use of Singleton design patterns).
Currently static .LIB files seem like the best choice. Still requires a re-link of the main executable, but I can live with that. Final executable is therefore relatively similar to what we have now - monolithic blob.
DLL's sound like the better option as it should allow for less re-compilation and a bit more clearly defined separation. What I don't fully understand at the moment is any issues with crossing the EXE<->DLL<->DLL boundaries. Throwing class instances and data around between components etc...
Anyone got any suggested reading/advice on this topic?