Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Ryan Pavlik]

Just wanted to mention that a similar module I wrote is my most popular
stack overflow post and had seen a number of pull requests and
acknowledgements, so it's seemingly widely used. While it's slightly more
complicated than required (when i first wrote it, I thought you had to use
the configured file to get it generated) it does pretty reliably work,
including with submodules. I'm happy to relicense it for inclusion with
CMake. (Bsl should be more permissive anyway)
SO answer: http:// 
stackoverflow.com 
/a/4318642/265522 

Module: https

://

github.com

/

rpavlik

/

cmake-modules

/blob/master/

GetGitRevisionDescription.cmake


Sample usage in practice:
https
://

github.com

/OSVR/

OSVR-Core

/blob/master/

cmake-local
/

Version.cmake


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.

Hope this is useful and saves some time reinventing wheels.

Ryan

On Tue, Oct 6, 2015, 4:41 PM Ben Boeckel  wrote:

> On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> > thanks for the feedback, i've included most of it.
> >
> > Regarding the configure/build issue: that indeed is inconvenient and may
> > cause irritation. on the other side, if there has been git activity
> > fussing with any source files affecting the build, cmake will run again
> > and hence capture the possibly new git info. so the case where you
> > change the revision after configure to an extent where cmake will not
> > automatically re-run is uncommon, at least for my guessing.
> > however, i've included an explicit warning in the docs to raise
> awareness.
>
> Well, without depending on every file in the source tree, it will just
> be wrong rather than causing excess configure runs. Adding something
> like "configure this file at build time" setup would need to be the
> basis though (basically porting and cleaning up sprokit_configure_file()
> into CMake as deferred_configure_file() or something similar would work).
>
> > i'm happy to provide a suitable procedure that is flexible enough;
> > providing scripts that configure files (like with sprokit) seems too
> > specific as people might want to have a single "config.h" file or so
> > containing more than just the git info.
>
> The sprokit mechanism configures any file using code to determine some
> of the variables at build time. It is by no means limited to just header
> files. The code injection is a little clunky (being a string and all),
> but it could also be changed to an include() statement with an extra
> depends on that included file. In fact, with include(), adding support
> for SVN, Mercurial and others would be pretty simple as well rather than
> duplicating all this for each revision system.
>
> > i've thought about the possibility to generate an explicit
> > "git_version.h" file to include, but that 1) restricts possible
> > languages and 2) will require an extra build target that is run each
> > build etc. any thoughts?
>
> Well, 

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Daniel Wirtz]

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 +, 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


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Ben Boeckel]

On Thu, Oct 08, 2015 at 17:16:33 +0200, Daniel Wirtz wrote:
> @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.

OK, that info is useful there, but *those* results should not end up in
the build itself. The documentation needs to be clear about this.

> @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.

No, just that you could say any of:

configure_revision_info(git "${source}" "${dest}")
configure_revision_info(cvs "${source}" "${dest}")
configure_revision_info(hg "${source}" "${dest}")

and then the generated file does:

include("RevisionExtract_${source_control}")

so that other source control systems can have "get relevant info"
modules to run at build time rather than baking git magic into the file
directly.

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Ben Boeckel]

On Thu, Oct 08, 2015 at 13:10:54 +, 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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Ben Boeckel]

On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> thanks for the feedback, i've included most of it.
> 
> Regarding the configure/build issue: that indeed is inconvenient and may 
> cause irritation. on the other side, if there has been git activity 
> fussing with any source files affecting the build, cmake will run again 
> and hence capture the possibly new git info. so the case where you 
> change the revision after configure to an extent where cmake will not 
> automatically re-run is uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.

Well, without depending on every file in the source tree, it will just
be wrong rather than causing excess configure runs. Adding something
like "configure this file at build time" setup would need to be the
basis though (basically porting and cleaning up sprokit_configure_file()
into CMake as deferred_configure_file() or something similar would work).

> i'm happy to provide a suitable procedure that is flexible enough; 
> providing scripts that configure files (like with sprokit) seems too 
> specific as people might want to have a single "config.h" file or so 
> containing more than just the git info.

The sprokit mechanism configures any file using code to determine some
of the variables at build time. It is by no means limited to just header
files. The code injection is a little clunky (being a string and all),
but it could also be changed to an include() statement with an extra
depends on that included file. In fact, with include(), adding support
for SVN, Mercurial and others would be pretty simple as well rather than
duplicating all this for each revision system.

> i've thought about the possibility to generate an explicit 
> "git_version.h" file to include, but that 1) restricts possible 
> languages and 2) will require an extra build target that is run each 
> build etc. any thoughts?

Well, you will indeed never have a "nothing to do" build with such a
target, but such information is effectively derived from "this depends
on every file in the tree tracked by git as well as the .git/HEAD,
.git/index, and .git/refs/tags/* files" so "always something to do"
isn't that far off. The step (in sprokit) takes ~0 time to run
anyways[1], so speed isn't an issue.

--Ben

[1]45 build trees took < 2 seconds, so figuring for some overhead for
exec() of ninja itself and ninja scanning, the overhead for checking the
git revision is < .05s for a smallish source tree. Something like
webkit's git mirror could take a while though.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Daniel Wirtz]

Hey all,

thanks for the feedback, i've included most of it.

Regarding the configure/build issue: that indeed is inconvenient and may 
cause irritation. on the other side, if there has been git activity 
fussing with any source files affecting the build, cmake will run again 
and hence capture the possibly new git info. so the case where you 
change the revision after configure to an extent where cmake will not 
automatically re-run is uncommon, at least for my guessing.

however, i've included an explicit warning in the docs to raise awareness.

i'm happy to provide a suitable procedure that is flexible enough; 
providing scripts that configure files (like with sprokit) seems too 
specific as people might want to have a single "config.h" file or so 
containing more than just the git info.
i've thought about the possibility to generate an explicit 
"git_version.h" file to include, but that 1) restricts possible 
languages and 2) will require an extra build target that is run each 
build etc. any thoughts?


Daniel

Signed-off-by: Daniel Wirtz 
---
 Modules/FindGit.cmake | 145 
+++---

 1 file changed, 138 insertions(+), 7 deletions(-)

diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake
index b4f7b4b..e8a86f5 100644
--- a/Modules/FindGit.cmake
+++ b/Modules/FindGit.cmake
@@ -2,28 +2,75 @@
 # FindGit
 # ---
 #
+# This module helps finding a local Git_ installation and provides 
convenience functions for common Git queries.

 #
+# .. _Git: http://git-scm.com/
 #
-# The module defines the following variables:
+# Defined variables
+# "
 #
-# ::
+# :variable:`GIT_EXECUTABLE`
+#Path to Git_ command line client
+# :variable:`GIT_FOUND`
+#True if the Git_ command line client was found
+# :variable:`GIT_VERSION_STRING`
+#The version of Git_ found (since CMake 2.8.8)
+#
+# Defined functions
+# "
+#
+# For convenience, the module provides the additional functions
+#
+# :command:`git_get_revision`
+# Get commit revision number information. +#
+# :command:`git_get_branch` +# Get current branch information.
 #
-#GIT_EXECUTABLE - path to git command line client
-#GIT_FOUND - true if the command line client was found
-#GIT_VERSION_STRING - the version of git found (since CMake 2.8.8)
+# **WARNING**
 #
-# Example usage:
+# If you use those functions at *configure* time and checkout a 
different Git_ revision after running :manual:`cmake(1)`,
+# the information from :command:`git_get_revision` or 
:command:`git_get_branch` will be outdated.
+# If you need to be sure, we recommend using 
:command:`add_custom_command` or :command:`add_custom_target` in 
conjunction with
+# the :manual:`cmake(1)` script mode (:code:`-P`) to ensure the Git_ 
information is obtained at *build* time.  +# +#

+# Example usage
+# "
 #
 # ::
 #
 #find_package(Git)
 #if(GIT_FOUND)
 #  message("git found: ${GIT_EXECUTABLE}")
+#  git_get_branch(GITBRANCH)
+#  message("current branch at ${CMAKE_CURRENT_SOURCE_DIR}: 
${GITBRANCH}")

 #endif()
+#
+# Details
+# """
+#
+# .. variable:: GIT_EXECUTABLE
+#
+#Returns the full path to the Git_ executable to use in e.g. 
:command:`add_custom_command` like

+#
+# ::
+#
+#add_custom_command(COMMAND ${GIT_EXECUTABLE} clone 
https://github.com/myrepo mydir)

+#+# .. variable:: GIT_FOUND
+#
+#Boolean variable set to TRUE if a local Git_ was found, FALSE else.
+# +# .. variable:: GIT_VERSION_STRING
+#
+#The output of :code:`git --version`
+

#=
 # Copyright 2010 Kitware, Inc.
 # Copyright 2012 Rolf Eike Beer 
+# Copyright 2015 Daniel Wirtz 
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -73,7 +120,91 @@ endif()
 # Handle the QUIETLY and REQUIRED arguments and set GIT_FOUND to TRUE if
 # all listed variables are TRUE
 -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+include(FindPackageHandleStandardArgs)
 find_package_handle_standard_args(Git
   REQUIRED_VARS GIT_EXECUTABLE
   VERSION_VAR GIT_VERSION_STRING)
+
+# Convenience Git repo & branch information functions
+
+#.rst:
+# .. command:: git_get_revision
+#
+# ::
+#
+# git_get_revision(VARNAME
+#[SHORT]
+#[GIT_OPTIONS] 
+#[WORKING_DIRECTORY] )
+#
+# Obtain Git_ revision information using the rev-parse_ command. 
Effectively calls :code:`rev-parse [GIT_OPTIONS] --verify -q HEAD`.

+#
+# ``VARNAME``
+#The workspace variable name to assign the result to.
+#
+# ``SHORT``
+#Optional. If set to TRUE, the short revision string will be 
returned. Otherwise, the full revision hash is returned.

+#
+# ``GIT_OPTIONS``
+#

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Rolf Eike Beer]

+endif()
+set(${VARNAME} ${RES} PARENT_SCOPE)
+endfunction()
\ No newline at end of file


Bug ;)
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Pascal Bach]

Hi Daniel

I just wanted to let you know that I was planing to bring a git versioning 
script upstream soon.
It is based on the following sequence of commands: 
https://github.com/bufferoverflow/proxyme/blob/master/CMakeLists.txt#L5

It tries to generate a version string of the following form: {git-tag} 
({git-hash}-{dirty}).

It will try to do the best possible to figure out the tag:
-If on a valid tag: v1.1.0 (f567657)
-If no tag but clean workdir: undefined (f567657)
-If not tag and working tree with uncommited changes: undefined 
(f567657-dirty)

This -dirty convention is the same as used by u-boot and the linux kernel.
Maybe you can incorperate these ideas into your solution too.

Regards
Pascal

Am 05.10.2015 um 12:50 schrieb Daniel Wirtz:
> Hey all,
>
> thanks for the feedback, i've included most of it.
>
> Regarding the configure/build issue: that indeed is inconvenient and may 
> cause irritation. on the other side, if there has been git activity fussing 
> with any source files affecting the build, cmake will run again and hence 
> capture the possibly new git info. so the case where you change the revision 
> after configure to an extent where cmake will not automatically re-run is 
> uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.
>
> i'm happy to provide a suitable procedure that is flexible enough; providing 
> scripts that configure files (like with sprokit) seems too specific as people 
> might want to have a single "config.h" file or so containing more than just 
> the git info.
> i've thought about the possibility to generate an explicit "git_version.h" 
> file to include, but that 1) restricts possible languages and 2) will require 
> an extra build target that is run each build etc. any thoughts?
>
> Daniel
>
> Signed-off-by: Daniel Wirtz 
> ---
>  Modules/FindGit.cmake | 145 
> +++---
>  1 file changed, 138 insertions(+), 7 deletions(-)
>
> diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake
> index b4f7b4b..e8a86f5 100644
> --- a/Modules/FindGit.cmake
> +++ b/Modules/FindGit.cmake
> @@ -2,28 +2,75 @@
>  # FindGit
>  # ---
>  #
> +# This module helps finding a local Git_ installation and provides 
> convenience functions for common Git queries.
>  #
> +# .. _Git: http://git-scm.com/
>  #
> -# The module defines the following variables:
> +# Defined variables
> +# "
>  #
> -# ::
> +# :variable:`GIT_EXECUTABLE`
> +#Path to Git_ command line client
> +# :variable:`GIT_FOUND`
> +#True if the Git_ command line client was found
> +# :variable:`GIT_VERSION_STRING`
> +#The version of Git_ found (since CMake 2.8.8)
> +#
> +# Defined functions
> +# "
> +#
> +# For convenience, the module provides the additional functions
> +#
> +# :command:`git_get_revision`
> +# Get commit revision number information. +#
> +# :command:`git_get_branch` +# Get current branch information.
>  #
> -#GIT_EXECUTABLE - path to git command line client
> -#GIT_FOUND - true if the command line client was found
> -#GIT_VERSION_STRING - the version of git found (since CMake 2.8.8)
> +# **WARNING**
>  #
> -# Example usage:
> +# If you use those functions at *configure* time and checkout a different 
> Git_ revision after running :manual:`cmake(1)`,
> +# the information from :command:`git_get_revision` or 
> :command:`git_get_branch` will be outdated.
> +# If you need to be sure, we recommend using :command:`add_custom_command` 
> or :command:`add_custom_target` in conjunction with
> +# the :manual:`cmake(1)` script mode (:code:`-P`) to ensure the Git_ 
> information is obtained at *build* time.  +# +#
> +# Example usage
> +# "
>  #
>  # ::
>  #
>  #find_package(Git)
>  #if(GIT_FOUND)
>  #  message("git found: ${GIT_EXECUTABLE}")
> +#  git_get_branch(GITBRANCH)
> +#  message("current branch at ${CMAKE_CURRENT_SOURCE_DIR}: ${GITBRANCH}")
>  #endif()
> +#
> +# Details
> +# """
> +#
> +# .. variable:: GIT_EXECUTABLE
> +#
> +#Returns the full path to the Git_ executable to use in e.g. 
> :command:`add_custom_command` like
> +#
> +# ::
> +#
> +#add_custom_command(COMMAND ${GIT_EXECUTABLE} clone 
> https://github.com/myrepo mydir)
> +#+# .. variable:: GIT_FOUND
> +#
> +#Boolean variable set to TRUE if a local Git_ was found, FALSE else.
> +# +# .. variable:: GIT_VERSION_STRING
> +#
> +#The output of :code:`git --version`
> +
>
> #=
>  # Copyright 2010 Kitware, Inc.
>  # Copyright 2012 Rolf Eike Beer 
> +# Copyright 2015 Daniel Wirtz 
>  #
>  # Distributed under the OSI-approved BSD License (the "License");
>  # see accompanying file Copyright.txt for details.
> @@ -73,7 +120,91 @@ endif()
>  # Handle the 

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Brad King]

On 09/25/2015 11:32 AM, Daniel Wirtz wrote:
> here's my proposal for the git convenience functions, see 
> http://public.kitware.com/pipermail/cmake/2015-September/061516.html

Thanks for working on this.

> additionally, can someone hint me as to how to build the html-help 
> locally? i want to be able to check the generated help output .. some 
> quick search did not get me any how-to's.

Configure CMake with -DSPHINX_HTML=ON.  Be sure you have python-sphinx
installed.  Point SPHINX_EXECUTABLE at the `sphinx-build` command if
needed.

> +#git_get_revision(VARNAME [WORKING_DIRECTORY])
> +#git_get_branch(VARNAME [WORKING_DIRECTORY])

Please see the cmake-developer(7) manual section on documenting commands:

 http://cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#cmake-domain

Run

  git grep '\.\. command::' -- Modules

to see some examples.

> +# Added by Daniel Wirtz

This information is recorded in the commit history and so is not needed
here.  You can add a line to the copyright block if you want.  Just be
sure it passes the ModuleNotices test.

> +function(git_get_revision VARNAME)
[snip]
> +execute_process(COMMAND ${GIT_EXECUTABLE} rev-list --max-count=1 HEAD

Perhaps:

 git rev-parse --verify -q HEAD

?

> +function(git_get_branch VARNAME)
[snip]
> +execute_process(COMMAND ${GIT_EXECUTABLE} describe --all

Perhaps:

 git symbolic-ref -q HEAD

?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

[Ben Boeckel]

On Fri, Sep 25, 2015 at 17:32:24 +0200, Daniel Wirtz wrote:
> Hello all,
> here's my proposal for the git convenience functions, see 
> http://public.kitware.com/pipermail/cmake/2015-September/061516.html
> 
> i've also created a pull request 
> https://github.com/Kitware/CMake/pull/185 (before i read 
> CONTRIBUTING.rst, sorry)

Thanks!

One thing that I think should be done is to allow for a format to be
specified. Some will want the long hash, short hash, describe output,
commit date, etc.

However, I think there is a larger issue: this is setting people up for
failure if they want the hash of the source tree in their build. These
commands really should be run at *build* time because cmake will not
necessarily rerun if the git commit changes which makes it easy for the
git data to be silently wrong.

See this[1] code for what should be done for full "put the git hash in
the build" support including tarballs without a .git directory. The
sprokit_configure_file basically adds a command which runs a script to
configure the file at build time (the list of variables are passed
explicitly).

> additionally, can someone hint me as to how to build the html-help 
> locally? i want to be able to check the generated help output .. some 
> quick search did not get me any how-to's.

You need to have sphinx enabled and then set SPHINX_HTML=ON.

--Ben

[1]https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers