Johannes Sixt <johannes.sixt@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
