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, 7 insertions, 2 deletions

diff --git a/Makefile.SH b/Makefile.SH
index ff50cfd0d7..9ad8b6f102 100644
--- a/Makefile.SH
+++ b/Makefile.SH
@@ -371,7 +371,10 @@ CCCMD    = `sh $(shellflags) cflags "optimize='$(OPTIMIZE)'" $@`
 
 CCCMDSRC = `sh $(shellflags) cflags "optimize='$(OPTIMIZE)'" $<`
 
+# we dont include lib/Config_git.pl here, as it causes circular dependencies
 CONFIGPM = lib/Config.pm lib/Config_heavy.pl
+# so we add it here:
+CONFIGPM_EXTRA = $(CONFIGPM) lib/Config_git.pl
 
 CONFIGPOD = lib/Config.pod
 
@@ -540,7 +543,8 @@ sperl.i: perl.c $(h)
 make_patchnum:
 	sh $(shellflags) make_patchnum.sh
 
-perl$(OBJ_EXT): .patchnum .sha1
+# make sure that we recompile perl.c if .patchnum changes
+perl$(OBJ_EXT): .patchnum unpushed.h
 
 translators:	miniperl$(EXE_EXT) $(CONFIGPM) FORCE
 	@echo " "; echo "	Making x2p stuff"; cd x2p; $(LDLIBPTH) $(MAKE) all
@@ -1217,7 +1221,8 @@ _tidy:
 	-cd utils; $(LDLIBPTH) $(MAKE) clean
 	-cd x2p; $(LDLIBPTH) $(MAKE) clean
 	-rm .patchnum
-	-rm .sha1
+	-rm lib/Config_git.pl
+	-rm unpushed.h
 	-@for x in $(DYNALOADER) $(dynamic_ext) $(static_ext) $(nonxs_ext) ; do \
 	$(LDLIBPTH) sh ext/util/make_ext clean $$x MAKE=$(MAKE) ; \
 	done