I prefer expressing the difference between project a solution owns and projects it does not own (dependencies) with the help of Visual Studio’s solution folders. It’s a trick I didn’t […]

Laatst had ik met een collega een discussie over hoe de structuur van onze code repository dient te zijn. Op dat moment kon ik niet zo snel beantwoorden waarom ik voor- danwel tegenstander van een bepaalde indeling ben, dus heb ik er nog eens over nagedacht.

In dit geval gaat het om verschillende Visual Studio Solutions (.sln) en hun C++ projecten (.vcxproj). Als ik een indeling zou moeten maken, zijn mijn afwegingen als volgt.

Ownership en containment

Solution

Een solution bevat projecten waarvan hij al dan niet owner is. Bij een solution als MyApplication.sln, verwacht ik een project MyApplication.vcxproj. De solution is owner van dit project, het hoofdproject. Het project kan daarnaast nog dependencies hebben op andere projecten. Deze dependencies zijn ofwel specifiek voor dit project, ofwel generiek en herbruikbaar. De solution bevat alle projecten waarvan de projecten waar hij eigenaar van is direct of indirect afhankelijk zijn. D.w.z. MyApplication is afhankelijk van MyApplicationLib, welke op haar beurt weer afhankelijk is van GenericLib. De solution bevat alle drie deze projecten. Dat lijkt heel voor de hand liggend, maar het komt nogal eens voor dat een project afhankelijk is van een library die niet in de solution is opgenomen, waardoor een linker error optreedt tenzij je de dependency handmatig vantevoren los bouwt. Niet fraai.

A while ago I had a discussion with a colleague on what the structure of our code repository ought to be. At the time, I couldn’t find the words to explain why I prefer one strategy over another, so I’ve given it some more thought.

In this case we’re talking about several Visual Studio Solutions (.sln) and their C++ projects (.vcxproj). If I were to choose a directory structure, my considerations would be as follows.

Ownership and containment

Solution

A solution contains projects that it may or may not own. I expect a solution like MyApplication.sln to contain a project MyApplication.vcsproj. The solution owns this project, the main project. The project could have dependencies on other projects of course. These dependencies are either specific for this project, or generic and reusable. The solution contains all projects that the projects it owns directly or indirectly depend on. I.e. My Applicaiton depends on MyApplicationLib, which in turn depends on GenericLib. The solutoin contains all three projects. It may seem obvious, but it’s quite common to find a project that depends on a library that is not included in the solution, causing a linker error unless you built this additional dependency manually beforehand. Not pretty.