Use only Git commands in git_info

[robertodr]

This PR removes the need for CMake regexes to find the commit author name.
Moreover, the header can be generated in a custom directory and with a custom name.

@bast @miroi I have fixed the test and fine-tuned the implementation:

1. I have substituted the add_custom_command in git_info.cmake with a CMake function generate_git_info_header (the name can be changed) to fine-tune how the header is generated. The user can now choose location and name. If no arguments are provided to the function, this falls back to the previous implementation, i.e. generate a git_info.h header in ${PROJECT_BINARY_DIR}
2. I have remove the git_info_sub.cmake file, since it is no longer necessary.

[robertodr]

@bast This path is hardcoded. I was not able to find a permanent fix.

[miroi]

Hi @robertodr ,

is there some requirements as to the git version ? Change is based on git flags, would be good to know what is the lowest git version...

[robertodr]

@miroi The oldest version of Git I have access to is 1.7.1 and these commands work fine.
Might be that for Git <= 1.6 git log should be used instead of git show:
For the commit hash:

git --no-pager log -1 --pretty=format:"%h" -n 1

For the author name:

git --no-pager log -1 --pretty=format:"%aN" -n 1

For the commit date:

git --no-pager log -1 --pretty=format:"%ad" -n 1

[bast]

Thanks! Can you summarize in one or two sentences what has changed? A bit tricky to see from the diff. Why is the test failing? You write that a path is hardcoded - how would you ideally like the code to be if it was not hardcoded? In other words what did you have in mind?

[robertodr]

@bast Before my changes that line read ${CMAKE_CURRENT_LIST_DIR}/git_info.h.in Doing that within a function returns the location from where it was called, which can now be anywhere in the CMake code.
Since the CMake files need not necessarily be under ${PROJECT_SOURCE_DIR}/cmake I think that line could be problematic.

[bast]

Do you have an idea why the OS X tests failed?

[bast]

The hardcoding can be solved like this:

diff --git a/modules/git_info/git_info.cmake b/modules/git_info/git_info.cmake
index f499ddc..26f00f2 100644
--- a/modules/git_info/git_info.cmake
+++ b/modules/git_info/git_info.cmake
@@ -11,6 +11,9 @@
 #   fetch:
 #     - "%(url_root)modules/git_info/git_info.h.in"

+
+set(_current_dir ${CMAKE_CURRENT_LIST_DIR})
+
 function(generate_git_info_header)
   # _header_location: where the Git info header file should be generated
   # _header_name: the Git info header name, complete with extension (.h, .hpp, .hxx or whatever)
@@ -61,7 +64,7 @@ function(generate_git_info_header)
   endif()

   configure_file(
-    ${PROJECT_SOURCE_DIR}/cmake/downloaded/git_info.h.in
+    ${_current_dir}/git_info.h.in
     ${_header_location}/${_header_name}
     @ONLY
     )

Also I wonder whether we should not drop the default parameters but always require explicit parameters from the outside to simplify code and make things more explicit.

[robertodr]

@bast I have integrated your modifications. The failure on Mac seems unrelated to this PR, maybe a failure in running update.py?

[bast]

Thanks! Looks good now. I will test a bit more on my side and integrate very soon.

[bast]

Merged - however I will remove the defaults and the function needs to be called explicitly always. I think this is better.

[robertodr]

I left the default arguments not to hurt existing code using this module. I fully agree with you, explicit is better than implicit.

[bast]

I have changed it to explicit. The change anyway requires codes to add at least one line.