For most software packages, untar-autoconf/make configure-configure-make
is the preferred way to build the package; not so for Git. But the
presence of the make target makes people believe so.
Try and make people use "make configure" only when they are sure they
need to.
Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>
---
This does not help with people running autoconf themselves, of course.
But we keep answering questions about failed configure attempts.
On an annecdotical note: When I decided to switch to a dvcs, I failed building
Git (with configure) and tried out hg instead. Imagine!
Makefile | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 1f1ce04..430c096 100644
--- a/Makefile
+++ b/Makefile
@@ -1744,11 +1744,18 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
endif # NO_PYTHON
configure: configure.ac
+ifdef USEAUTOCONF
$(QUIET_GEN)$(RM) $@ $<+ && \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$< > $<+ && \
autoconf -o $@ $<+ && \
$(RM) $<+
+else
+ @echo "Using the Makefile and defining variables in config.mak is the"
+ @echo "preferred way of building Git. Please use"
+ @echo "USEAUTOCONF=1 make configure"
+ @echo "if you are really sure you need configure."
+endif
# These can record GIT_VERSION
git.o git.spec \
--
1.7.3.1.184.g5b1fd
--
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