Request for comments...

I might start a forum thread on this later, but I want to do a bit of research on it first before opening it up for more widespread comment...

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?