From: Junio C Hamano Date: Wed, 23 Jul 2008 18:31:03 GMT Subject: Re: [PATCH 5/9] Allow the built-in exec path to be relative to the command invocation path Message-ID: <7vfxq0e9lk.fsf@gitster.siamese.dyndns.org> In-Reply-To: <1216667998-8879-6-git-send-email-johannes.sixt@telecom.at> Johannes Sixt 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.