Thank you very much for this!
I had MSVC running on Linux under Wine, but didn't have a makefile to build projects with. I needed the makefile because although the MSVC compiler worked with Wine, the MSBuild system didn't, so I had no easy way to build projects from a project file. Typical compiler invocations had a lot of flags passed to the compiler, so it was an excessive pain to make manual calls to the compiler by hand.
The client side code duplication also used to bother me concerning Git submodules. I didn't like the idea of having a whole copy of the SDK in every level project folder.
Even worse, if you use an API both directly and indirectly, such as using Outpost2DLL directly, and another API, say OP2Helper, which also uses Outpost2DLL, then you can end up importing Outpost2DLL from two different levels, and have two copies of it in the same level project. Even more confusing, the two copies might be pinned to different versions.
Project
- Outpost2DLL
- OP2Helper
- Outpost2DLL
I would like to avoid duplicate copies within a single parent project, and use a more flat dependency model.
Project
- Outpost2DLL
- OP2Helper
An alternative structure, is to have a parent master project that includes all the sub projects. This is basically how the SVN layout works.
MasterProject
- API
- Outpost2DLL
- OP2Helper
- HFL
- Levels
- Project 1
- Project 2
- Project 3
- ...
That would be one way of keeping the structure flat. The downside though, is all projects are then pinned to the same version of the API, which is not necessarily correct. If I make updates to an API, I don't want to have to update everyone else's project that uses that API. Likely such projects would just get out of date, and might fail to compile with the newer API libraries.
Per project pinning of dependencies makes the most sense. I think it can still be done in a way that keeps it reasonably flat, while also isolating separate projects from API upgrades.
As for duplicating the API in each project, I think that's something you just have to live with if you want a solution that is actually correct, and supports different projects building against different API versions, which you really need when you have multiple authors, and not every author necessarily wants to share their source code. By trying to save disk space, you'd have a less correct solution.
These days, disk space is cheap and plentiful.