much better git related version numbering in our (*nix for now) build process

The net result of this patch is to make available via Config.pm and -v/-V the
details about the git version info we have available for the build. When built within
a git repository git is queried directly. When built from a snapshot or bundle
it is assumed that the source is unchanged, and that the required details are
avaialble in a file called .patch, whose format current is a four field string
in the following format: "$branchname $date.$time $sha1 $describe". The
generator of these files currently resides on camel.booking.com.

* git-describe is now used more directly with -v.
	When the prefix of git-describe matches the version number
	as determined by the defines in patchlevel.h then we use ONLY
	the git-describe output, otherwise we include
	the git describe in parenthesis after the version number. Either way
	the describe text is optionally followed by a star should there be
	uncommitted changes.
	eg: This is perl, v5.11.0 (GitLive-blead-136-g58ca560) built for i686-linux
	or: This is perl, v5.11.0-1-g58ca560 built for i686-linux
	or: This is perl, v5.11.0 built for i686-linux

* include the SHA1 in perl -V summary, and automatically include unpushed
	commits in the registered patches list

* include various git/version/.patch details in %Config, as follows:

	git_commit_id             # sha1 of HEAD
	git_ancestor              # ancestor in $remote/$branch (presumably canonical)
	git_describe              # git describe
	git_branch                # current branch
	git_uncommitted_changes   # "true" if there are any, empty otherwise
	git_unpushed_commits      # List of sha1's of unpushed commits
	git_commit_id_title       # Used to make the perl -V summary output

Additionally one more value is added depending on build process used: when
building from an rsynced snapshot (or any dist including a file called
.patch) then the second field will be used to populate the
"git_snapshot_date" field. Otherwise if built in a git directory (as is hopefully
recommended these day) then the field will be "git_commit_date" which will be the
commit date of HEAD.

This patch introduces two new files (on top of .patchnum) that will be generated by
make_patchnum.sh: "lib/Config_git.pl" and "unpushed.h", the former is used to make
git data available to Config.pm/%Config without rebuilding everything else, and the
second is used to expose unpushed commits (if any) via the registered patch facility
of patchlevel.h

1 files changed, 5 insertions, 5 deletions

diff --git a/cflags.SH b/cflags.SH
index 6e6e8a950e..132f466a92 100755
--- a/cflags.SH
+++ b/cflags.SH
@@ -297,12 +297,12 @@ for file do
     opmini) ;;
     pad) ;;
     perl) 
-        if [ -f .patchnum -a -n "$(cat .patchnum)" ] ; then
-                ccflags="-DPERL_PATCHNUM=`cat .patchnum` $ccflags"
-        fi
-        if [ -f .sha1 -a -n "$(cat .sha1)" ] ; then
-                ccflags="-DPERL_GIT_SHA1=`cat .sha1` $ccflags"
+        if [ -f .patchnum -a -n "$(awk 'BEGIN{ORS=""} /describe:/ {print $1}' .patchnum)" ] ; then
+                ccflags="-DPERL_PATCHNUM=$(awk 'BEGIN{ORS=""} /describe:/ {print $2}' .patchnum) $ccflags"
         fi
+	if [ -f .patchnum -a -n "$(awk 'BEGIN{ORS=""} /status:/ {print $2}' .patchnum)" ] ; then
+                ccflags="-DPERL_GIT_UNCOMMITTED_CHANGES=$(awk 'BEGIN{ORS=""} /status:/ {print $2}' .patchnum) $ccflags"
+	fi
         ;;
     perlapi) ;;
     perlmain) ;;