[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