Robin Vobruba wrote: > We also recently moved from SVN to GIT with our main repository. > Because of the way GIT works, we would like CMake to check for file > modification based on file contents, rather then timestamps. This > would let us use the advantages of GIT to its fullest, save us from > keeping a separate local repository for each branch, and in general > make development much more comfortable. > If you want me to further explain all this, i would be happy to do that.
I'm guessing you have the following workflow: - One source tree, multiple branches - One build tree per branch - Manually checkout proper branch before using associated build tree and the problem you are seeing is that switching away from a branch and back to it rebuilds things even though nothing on the branch changed. This problem occurs with any version control tool. It is just more obvious in git because it enables workflows with lots of branches. FYI, git optimizes multiple local clones using hardlinks when possible. It also does have some support for multiple work trees: http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/workdir/git-new-workdir;h=993cacf324b8595e5be583ff372b25353c7af95c;hb=c123b7c5fb596d93cd015645212c379fc3c381d5 A content-based build tool would use a file's timestamp only to determine when to update a hash of its content. A rebuild would occur only when the hash changes. Initial builds with such a tool would be slower because it would have to compute a hash of every file the first time. Incremental builds would be nearly as fast as timestamp-only solutions as long as only a few files change. Branch-change builds (in the above workflow) would be much faster. As other have commented in this thread, CMake is a build system _generator_. The final build is done by make (or VS, or Xcode), not CMake. Support for content-based build rules requires a new build tool and a new generator in CMake to generate its input files. Creation of such a tool is currently outside CMake's scope. If someone were to create one, we would be willing to add a generator for it. -Brad _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
