Re: [PATCH 5/9] Allow the built-in exec path to be relative to the command invocation path

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> If $(gitexecdir) is relative, it is interpreted relative to the command's
> invocation path, which usually is $(bindir).
>
> The Makefile rules were written with the assumption that $(gitexecdir) is
> an absolute path. We introduce a separate variable that names the
> (absolute) installation directory.
>  ... 
> +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
> +gitexec_instdir = $(bindir)/$(gitexecdir)
> +else

Can we please have a brief comment in the Makefile near we define mandir,
infodir, gitexecdir and friends about this "relative to $(bindir)"
business?

Perhaps like:

 Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 23f2185..8fa8f9a 100644
--- a/Makefile
+++ b/Makefile
@@ -171,6 +171,12 @@ ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
 
 prefix = $(HOME)
+
+# Among these variables, gitexecdir and/or template_dir can be
+# specified as a relative path ../some/where/else; this is interpreted
+# as relative to $(bindir) and "git" at runtime figures out where they
+# are based on the path to the executable.  This can help installing the
+# suite in a relocatable way.
 bindir = $(prefix)/bin
 mandir = $(prefix)/share/man
 infodir = $(prefix)/share/info

Note that I just listed two variables out of thin air without studying;
you might be making other variables capable of relative path, in which
case they should also be listed there.