[cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cmake at cmake.org

Daniel Wirtz daniel.wirtz at simtech.uni-stuttgart.de
Thu Oct 8 11:16:33 EDT 2015


Yo,

@ben / "I honestly don't think configure time git information is all 
that useful anyways"
in our scenario, the configure time information is actually more 
relevant. we use the "superbuild" scheme and also provide
a "support" target that collects configuration info and variables if 
something goes wrong during builds. therein, the git information is 
crucial for us
if we want to track down the errors they encounter.
of course, this doesn't mean the build-time info is irrelevant.

@ben / "support for SVN, Mercurial and others"
so are we talking about a "GetCVSInfo"-type module here? if so, i think 
this will quickly grow too big and tedious to handle.
people change cvs systems for their source rarely, and changing the 
couple of commands upon cvs switching seems the more tidy way down the 
road (to me)

@ryan
thanks for mentioning.. now we kinda have three propositions regarding 
git version info "out there".

this leads me to the question on how the decision making process within 
the CMake devs is ideally organized?
should there be some "specifications" on what should be possible?

Daniel

Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044

On 10/08/2015 04:37 PM, Ben Boeckel wrote:
> On Thu, Oct 08, 2015 at 13:10:54 +0000, Ryan Pavlik wrote:
>> One addition I would have liked to have but haven't had time to do yet: the
>> ability to have a add custom command-based build time generation, instead
>> of our in addition to the CMake time generation. Some projects take a very
>> long time to generate, may cause visual studio to needlessly reload project
>> files, and you may only want the revision for a header file anyway. As you
>> can imagine, this would share much implementation with the configure time
>> code, and the prerequisite refactoring is why I haven't gotten around to
>> doing it yet.
> FYI, this is what sprokit's code does (based on
> sprokit_configure_file[1]). I honestly don't think configure time git
> information is all that useful anyways, so build-time generation is the
> only way sprokit does it (and it handles tarball builds just fine too).
>
> --Ben
>
> [1]https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake#L73



More information about the cmake-developers mailing list