Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris

From: Thomas Rast <hidden>
Date: 2016-06-15 22:53:12

Stefano Lattarini [off-list ref] writes:
+# 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 $$*")
There's 'command -v make'.  'man 1p command' on my system (opensuse
installs a bunch of POSIX reference material) says

       -v     (On  systems  supporting  the  User  Portability Utilities
              option.) Write a string to standard output that  indicates
              the pathname or command that will be used by the shell, in
              the current shell execution environment (see Shell  Execu-
              tion  Environment  ),  to  invoke command_name, but do not
              invoke command_name.

               * Utilities, regular  built-in  utilities,  command_names
                 including  a  slash  character, and any implementation-
                 defined functions that are found using the  PATH  vari-
                 able  (as  described in Command Search and Execution ),
                 shall be written as absolute pathnames.

So perhaps enough systems including Solaris "support the User
Portability Utilities option", and you can use this?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [RFC/PATCH] build: avoid possible confusion between GNU/XPG4 make on Solaris

From: Stefano Lattarini <hidden>
Date: 2016-06-15 22:53:12

On 03/02/2012 10:34 AM, Thomas Rast wrote:
Stefano Lattarini [off-list ref] writes:
quoted
+# 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 $$*")
There's 'command -v make'.  'man 1p command' on my system (opensuse
installs a bunch of POSIX reference material) says

       -v     (On  systems  supporting  the  User  Portability Utilities
              option.) Write a string to standard output that  indicates
              the pathname or command that will be used by the shell, in
              the current shell execution environment (see Shell  Execu-
              tion  Environment  ),  to  invoke command_name, but do not
              invoke command_name.

               * Utilities, regular  built-in  utilities,  command_names
                 including  a  slash  character, and any implementation-
                 defined functions that are found using the  PATH  vari-
                 able  (as  described in Command Search and Execution ),
                 shall be written as absolute pathnames.

So perhaps enough systems including Solaris "support the User
Portability Utilities option", and you can use this?
Thanks, I had completely forgotten about this "trick".  It works correctly
with both /bin/sh and /bin/ksh on all of NetBSD 5.1, OpenBSD 5.0 and
Solaris 10, as well as with bash (4.1.5) and dash (0.5.5.1) on my Debian
unstable.  I will post an updated patch later today (or this evening).

Regards,
  Stefano

[PATCH v2] build: avoid possible confusion between GNU/XPG4 make on Solaris

From: Stefano Lattarini <hidden>
Date: 2016-06-15 22:53:12

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":

        SUBDIR perl
    make: Warning: Ignoring DistributedMake -o option
    Usage : make [ -f makefile ][ -K statefile ]...
    make: Fatal error: Unknown option `-C'

This happens because the Git's Makefiles, when running on Solaris, sanitize
$PATH by prepending /usr/xpg6/bin and /usr/xpg4/bin to it, but 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; this happens because, in that setup,
the original GNU make process was invoked simply as "make".

To avoid such an issue, we instruct our Makefile to redefine $(MAKE) to
point to the absolute path of the originally-invoked make program.

Helped-by: Thomas Rast [off-list ref]
Signed-off-by: Stefano Lattarini <redacted>
---
 Makefile |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index e4f8e0e..e71d688 100644
--- a/Makefile
+++ b/Makefile
@@ -303,6 +303,21 @@ ifdef MSVC
 	uname_O := Windows
 endif
 
+# 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.
+original_MAKE := $(MAKE)
+MAKE := $(shell command -v $(firstword $(original_MAKE)) 2>/dev/null)
+ifeq ($(MAKE),)
+	MAKE := $(original_MAKE)
+else
+	MAKE += $(wordlist 2,$(words $(original_MAKE)),$(original_MAKE))
+endif
+
 # CFLAGS and LDFLAGS are for the users to override from the command line.
 
 CFLAGS = -g -O2 -Wall
-- 
1.7.9
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help