Re: [PATCH] Replace hard-coded path with one configurable at make time

From: Chris Webb <chris@arachsys.com>
Date: Apr 4, 2010, 22:28 UTC
Message-ID: <20100404222801.GB31315@arachsys.com>
In-Reply-To: <7vk4sm7vao.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

>  * What's the point of making this configurable, other than "because we
>    can"?

I have a local patch against git to fix these paths, as I run it on slightly unusual systems with a non-standard directory layout (no /usr, but /local/bin in some cases) and I don't like to see incorrect paths compiled into my binaries. It occurred to me that if I want to fix it one way locally, others may well want to vary it too for different reasons, e.g. to add /opt/bin or /usr/gnu to the default path.

Ultimately, I guess it feels like it should be configurable rather than needing to be patched in the source for the same reason prefix or gitexecdir is, but this is definitely for a minority audience!

Were it just exec_cmd.c, I would just have changed it to use _PATH_DEFPATH from <paths.h> in preference to a make variable, as that should always give an appropriate value for a correctly put-together system and is a sensible place to treat as the central definition of 'default path'. However, in this case it's needed in the shell script too and I don't think I can easily get at _PATH_DEFPATH from there.

Show 10 quoted lines

>  * Use of "$(x_SQ)" is about protecting whitespaces and single quotes in
>    the literal from make and shell, but does not have anything to do with
>    protecting things like $foo in that literal from the location $x is
>    eventually embedded in.  As long as paths on DEFPATH do not have double
>    quote in it (which would be a sane assumption), the patch to exec_cmd.c
>    would work fine, but I don't know if you need an extra quoting when
>    DEFPATH is used in shell scripts.  E.g. DEFPATH=$GIT_EXEC_PATH:/usr/bin
>    would have GIT_EXEC_PATH expanded in mongoose configuration file, but
>    will not be expanded in exec_cmd.c, leading to an inconsistent
>    behaviour.

Oh I see, yes; I didn't worry about quoting it correctly in the generated shell script, assuming it would be reasonable... but if I'm assuming it's reasonable there's no point in the _SQ to protect the shell invoking sed in the first place.

I also notice that the makefile makes the assumption that ' might occur in pathological paths and so needs quoting, but then uses sed 's|x|y|g' for (say) @@PERL@@ which will break for other pathological paths containing | or \1 and so on. Tidying that up fully might be entertaining!

Cheers,

Chris.