On 03/02/2012 07:35 PM, Junio C Hamano wrote: > Stefano Lattarini <stefano.lattarini@xxxxxxxxx> 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? > 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 -- 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