>Number:         13625
>Category:       pkg
>Synopsis:       /bin/sh eval fails in common configure test when $MAKE contains '/'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 03 11:12:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Darrow
>Release:        NetBSD 1.5.1
>Organization:
	Wheaton College Computing Services
	Wheaton College, Wheaton, IL
>Environment:
System: NetBSD jdarrowpiii.wheaton.edu 1.5.2_ALPHA NetBSD 1.5.2_ALPHA (JDARROW) #0: Wed Aug 1 11:57:44 CDT 2001 jdarrow@michal.wheaton.edu:/var/src/sys/arch/i386/compile/JDARROW i386


>Description:
(Whether this is really a shell bug, an configure bug, or a "don't do
that" is debatable, but I wanted to send a pr on it in case anyone else
gets bitten by this...)

One of the tests used early on in current configure scripts is to test
whether the running make command sets $MAKE.  To do so, configure uses
the following shell fragment:

echo $ac_n "checking whether ${MAKE-make} sets \$MAKE""... $ac_c" 1>&4
set dummy ${MAKE-make}; ac_make=$2
if eval "test \"`echo '${'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  echo $ac_n "(cached) $ac_c" 1>&4
else
  cat > conftestmake <<\EOF
all:
	@echo 'ac_maketemp="${MAKE}"'
EOF
# GNU make sometimes prints "make[1]: Entering...", which would confuse us.
eval `${MAKE-make} -f conftestmake 2>/dev/null | grep temp=`
if test -n "$ac_maketemp"; then
  eval ac_cv_prog_make_${ac_make}_set=yes
else
  eval ac_cv_prog_make_${ac_make}_set=no
fi
rm -f conftestmake
fi
if eval "test \"`echo '$ac_cv_prog_make_'${ac_make}_set`\" = yes"; then
  echo "$ac_t""yes" 1>&4
  SET_MAKE=
else
  echo "$ac_t""no" 1>&4
  SET_MAKE="MAKE=${MAKE-make}"
fi

Unfortunately, the eval in the third line (marked above with ^^^^^) fails
if $MAKE currently contains '/' (e.g. if this was run as
'/usr/bin/make package' instead of just 'make package'.)  The failure
looks as follows:

checking whether /usr/bin/make sets $MAKE... eval: 1: Syntax error: Bad substitu
tion
*** Error code 2

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.

bash, on the other hand, which most of the autoconf developers are
probably running under linux, handles the substitution just fine - in
testing, I discovered that it only fails the eval if $MAKE starts with
'.', which would be quite contrived in this situation...  However, the
eval error given gives a little more insight as to what the breakage
actually looks like:
bash: ${ac_cv_prog_make_./make_set+set}: bad substitution
                        ^^^^^^
  this part would be /usr/bin/make in the NetBSD /bin/sh case above...
                                

>How-To-Repeat:
Start a package build as '/usr/bin/make package' instead of just
'make package' and watch it fail on things like devel/m4 (!), etc...

>Fix:
Workaround is "don't do that!", don't try to explicitly run /usr/bin/make,
just rely on the correct make being first in path.

For a longer term fix:
Should our sh's 'eval' be taught to handle a substitution containing
'/' (like bash does)?  It might have to if autoconf is going to do
tests like this...  Does POSIX say anything about this?

>Release-Note:
>Audit-Trail:
>Unformatted: