Stefano Lattarini [off-list ref] writes:
On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,
GNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing
in $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking
"make all":
After reading this explanation, my first reaction is that the prefixing of
path _is_ what is wrong. The prefixing is done to help a subset of
Solaris users who are unaware of /usr/xpg4/bin that are more POSIX than
what they have in /usr/bin, and that is what is hurting people like you
who know what you are doing and have suitable tools in other places, like
you do in /usr/local/bin.
And the real fix for your problem is _not_ an ugly override of $(MAKE)
like you do in this patch, I think. After all, somebody else who have a
tool in /usr/local/bin that is saner than what is in /usr/xpg4/bin may
suffer from the same issue for commands other than "make".
So the real solution would probably be to let you override how the
BROKEN_PATH_FIX works, no?
Ah... and I think we already have such a solution in our Makefile. Can't
you override SANE_TOOL_PATH in your config.mak instead?
+# This Makefile will possibly sanitize PATH by prepending system-specific
+# directories to it (e.g., /usr/xpg4/bin on Solaris). This can become
+# problematic for recursive make invocations, if one of those directories
+# contains a "make" program and the user has called GNU make by simply
+# invoking "make" (this can happen e.g. when GNU make has been installed
+# as /usr/local/bin/make). To avoid such issues, we redefine $(MAKE) to
+# point to the absolute path of the originally-invoked make program.
+# FIXME: this is ugly, and which(1) is quite unportable. Find a better
+# way to obtain the same effect.
+MAKE := $(shell set $(MAKE); m1=$$1; shift; \
+ m2=`which $$m1 2>/dev/null` && test -n "$$m2" || m2=$$m1; \
+ echo "$$m2 $$*")
+
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
On 03/02/2012 07:35 PM, Junio C Hamano wrote:
Stefano Lattarini [off-list ref] writes:
quoted
On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,
GNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing
in $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking
"make all":
After reading this explanation, my first reaction is that the prefixing of
path _is_ what is wrong. The prefixing is done to help a subset of
Solaris users who are unaware of /usr/xpg4/bin that are more POSIX than
what they have in /usr/bin, and that is what is hurting people like you
who know what you are doing and have suitable tools in other places, like
you do in /usr/local/bin.
And the real fix for your problem is _not_ an ugly override of $(MAKE)
like you do in this patch, I think. After all, somebody else who have a
tool in /usr/local/bin that is saner than what is in /usr/xpg4/bin may
suffer from the same issue for commands other than "make".
So the real solution would probably be to let you override how the
BROKEN_PATH_FIX works, no?
Ah... and I think we already have such a solution in our Makefile. Can't
you override SANE_TOOL_PATH in your config.mak instead?
Yes and no. While in hindsight I agree that using this already-provided
solution is much better than my ugly automatic munging of $(MAKE) (so yes,
let's scrap the present patch), I also think that if one is setting up the
configuration of the Git tree using the the autoconf-generated configure
script (as I do), he wants configure to Do The Right Thing automatically
in this regard too -- thus recognizing that /usr/xpg4/bin is already in
$PATH before /bin and /usr/bin, and setting up an appropriate default for
SANE_TOOL_PATH in 'config.make.autogen' accordingly.
What would you think of a patch in this direction?
Thanks,
Stefano
On a Solaris 10 system with Solaris make installed as '/usr/xpg4/bin/make',
GNU make installed as '/usr/local/bin/make', and with '/usr/local/bin'
appearing in $PATH *before* '/usr/xpg4/bin', I was seeing errors like this
upon invoking "make all":
SUBDIR perl
make: Warning: Ignoring DistributedMake -o option
Usage : make [ -f makefile ][ -K statefile ]...
make: Fatal error: Unknown option `-C'
This happened because the Git's Makefile, when running on Solaris,
automatically "sanitizes" $PATH by prepending '/usr/xpg6/bin' and
'/usr/xpg4/bin' to it, and in the setup described above such a behaviour
has the unintended consequence of forcing the use of Solaris make
in recursive make invocations -- even if the $(MAKE) macro is being
correctly used in them!
For developers that don't use the autoconf machinery, the best and easier
fix in such a situation is to properly override $(SANE_TOOL_PATH) in
config.mak. But a developer using the autoconf-generated configure script
to set up its Git source tree's configuration wouldn't expect to also have
to provide such an override *by hand* after having run configure; he would
either expect:
1) that the issue is automatically detected and transparently worked
around by configure; or at least
2) that a configure-time override telling how (and if) PATH is to be
sanitized is provided.
This change implements the second approach, which is less-ambitious but
also much less fragile. Note that, even if we should decide to implement
the first approach in the future, the code added by the present change
still be useful, allowing the user the possibility to override the
configure's choices in case they turn out wrong (in true autotools
spirit).
---
Hi Junio, sorry for the delay. Here is a simpler approach that worked
out well enough for me; the commit message should explain the rationales
and motivations for it in detail.
Regards,
Stefano
configure.ac | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8bb0f44..72f7958 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,6 +137,23 @@ if test -n "$1"; then
fi
])
+# Directories holding "saner" versions of common or POSIX binaries.
+AC_ARG_WITH([sane-tool-path],
+ [AS_HELP_STRING(
+ [--with-sane-tool-path=DIR-1[[:DIR-2...:DIR-n]]],
+ [Directories to prepend to PATH in build system and generated scripts])],
+ [if test "$withval" = "no"; then
+ withval=''
+ else
+ AC_MSG_NOTICE([Setting SANE_TOOL_PATH to '$withval'])
+ fi
+ GIT_CONF_APPEND_LINE([SANE_TOOL_PATH=$withval])],
+ [# If the "--with-sane-tool-path" option was not given, don't touch
+ # SANE_TOOL_PATH here, but let defaults in Makefile take care of it.
+ # This should minimize spurious differences in the behaviour of the
+ # Git build system when configure is used w.r.t. when it is not.
+ :])
+
## Site configuration related to programs (before tests)
## --with-PACKAGE[=ARG] and --without-PACKAGE
#
--
1.7.9