Interdependent projects with svn and CMake - looking for advice
I apologize for the long question, but this is something I've been pondering for a while and I can't come up with a good solution.
I'm part of a team that is working on multiple projects that depend on each other in a hierarchic开发者_如何转开发al manner, and I'm trying to iron out some issues. The projects are structured like so (this is for a game):
Utility
RenderSystem - depends on Utility PhysicsSystem - depends on Utility GameEngine - depends on Utility, RenderSystem, and PhysicsSystem Game - depends on Utility and GameEngine
We are using svn and CMake.
We have several programmers, each working on different components, and each time there is an update to, say, RenderSystem, the Game programmer doesn't want to recompile the whole thing.
We currently have svn set up like so:
Util
RS PS GE Game bin
The binaries need to be in the svn so that a programmer doesn't have to compile the ones they aren't working on. This means that, on the local side, the binaries have to be present in the source directory to link against, and those same binaries also have to be present in the build directory for the executables to run (dynamic linking).
When configuring CMake, each programmer chooses which projects they want to be built and which ones they want to just use the precompiled binaries for.
Whenever a project is built, the binaries are automatically copied to the bin folder (and thus committed to the svn). When a programmer updates and gets new binaries, they are copied to the build directory.
We don't have a build server at the moment, so having the binaries automatically built isn't an option.
There are several annoyances with this method:
- when committing, the commit window is cluttered with the .dlls and .libs
- conversely, when updating the update window is cluttered with .dlls and .libs
- if programmer A builds the whole thing and commits, programmer B will get a conflict with the dlls and lib files. This would only happen when when two programmers are working on a project in common, and since the binaries are generated from the code, it doesn't matter how the conflict will be resolved. This is an extra annoyance.
- sometimes a programmer will have two builds generated from the source, and when one is rebuilt, the binaries have to be copied from the bin folder to the other. This means CMake needs to add a build event to copy any binaries that are different during each build.
- each time a project is built, all binaries need to be copied from the source dir to the build dir (to update any that have been changed from from an external build) and then the binaries that were built need to be copied back from the build dir to the source dir. This makes for a lot of file copying and is error-prone.
- there are different binaries for debug and release, and if programmer A is building in debug mode while working, then forgets to build the release before committing, the headers and binaries will not match.
The current system accomplishes two main things that we'd like to keep: there is one root source directory that needs to be checked out and updated, nobody wants to mess with having multiple things to check out; and the entire thing does not have to be built by each programmer, they can build just what they are working on.
I'd love any suggestions on how to make this smoother. On the front end, it works fine, but the guy that has to actually deal with the CMake files (me) is pretty damn frustrated.
The link_directories command specifies the paths in which the linker should search for libraries (.lib files). You can use this to search first in the directory containing libraries the developer has chosen to build locally, then search in the directory containing libraries checked out of Subversion. Similarly, to run the application, developers must configure PATH to search for .dll files in the directory containing .dll files the developer has chosen to build locally, then search in the directory containing .dll files checked out of Subversion.
When you want to commit changed binaries to Subversion, first copy the locally built binaries to the working copy directory containing the binaries.
精彩评论