Christian Couder <chrisc...@tuxfamily.org> writes:
> @@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE
> +### Detect Python interpreter path changes
> +ifndef NO_PYTHON
> +TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
> +GIT-PYTHON-VARS: FORCE
> + @VARS='$(TRACK_VARS)'; \
> + if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
> + echo 1>&2 " * new Python interpreter location"; \
> + echo "$$VARS" >$@; \
> + fi
Do we have the same issue when you decide to use /usr/local/bin/sh
after building with /bin/sh set to SHELL_PATH?
- If yes, I presume that there will be follow-up patches to this
one, for SHELL_PATH, PERL_PATH, and TCLTK_PATH (there may be
other languages but I didn't bother to check). How would the use
of language agnostic looking TRACK_VARS variable in this patch
affect such follow-up patches?
- If no (in other words, if we rebuild shell-scripted porcelains
when SHELL_PATH changes), wouldn't it be better to see how it is
done and hook into the same mechanism?
- If no, and if the approach taken in this patch is better than the
one used to rebuild shell scripts (it may limit the scope of
rebuilding when path changes, or something, but again, I didn't
bother to check), then again follow-up patches to this one to
describe dependencies to build scripts in other languages in a
similar way to this patch would come in the future. The same
question regarding TRACK_VARS applies in this case.
By the way, "1>&2" is easier to read if written as just ">&2", I
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html