The current code always regenerates the version.h file, but cmake ignores these changes and doesn't rebuild main.o. How to check: - do a build on a clean git dir; you won't see the -dirty suffix - echo blah >> Changelog - run make - the cmake's output says that the version ends with -dirty, but the binary is not rebuilt A correct fix is apparently to use the add_custom_target command, perhaps as per [1]. In addition, I would prefer a solution without two custom .cmake files. Finally, the current automation creates version.h in the source tree, not in the build tree. I have not changed this yet because I suspect the idea behind this is to allow for building the release tarballs from a local git checkout which was built previously. I prefer a solution where there's a #define in some .h file which is set to "4.x.z-git" in the non-release revisions, then updated to "4.x.z+1" by hand when doing the release, and immediately turned into "4.x.z+1-git" in a next commit to master. The result of `git describe --dirty` always takes precedence, but having a manually maintained fallback makes sure that there's a correct value even when someone e.g. fetches a zip file from some random web frontend for git. I suspect this is just a matter of personal preference, though. Johannes, would you like a patch which does essentially what I just described? No promises on ETA, though. [1] http://stackoverflow.com/questions/1435953/how-can-i-pass-git-sha1-to-compiler-as-definition-using-cmake
Sorry for the late response. Your report slipped under my radar somehow. I believe the bug is fixed since revision fe1cc85 (2012-09-25), which introduced the add_custom_target command you mentioned as a fix. Regarding the version.h file in the source tree: you are right, the intention is to include a version.h file in release tarballs. Since most (all?) KDE projects use the releaseme script for creating such tarballs and fetching a tar/zip archive using another frontend leaves you with a crippled copy (no translations) of the source anyways, using the same script for adding the version.h file to the tarball was deemed acceptable. I'm closing the bug for now. If you feel that the current version.h mechanism seriously breaks your build-preference, feel free to reopen the bug.