`make check` fails if builddir path contains `=`

[Paul Hargrove]

The following is a portion of blk/Makefile.tests responsible for compile tests:

         ( set -x ; env                                  \
           UPCXX_CODEMODE=$(UPCXX_CODEMODE)              \
           UPCXX_THREADMODE=$$threadmode                 \
           UPCXX_NETWORK=$$network                       \
           $$upcxx_cmd $(upcxx_src)/$$src                \ 

In the case one's build directory has a name like build-cc=gnu, the expansion of $$upcxx_cmd to a fullpath will be misinterpreted as a variable assignment! The resulting failure mode is very non-intuitive failure to execute the source file! (sorry, I didn't preserve the actual text).

[Paul Hargrove]

Neither Linux nor macOS document -- in their man page for env, thought both appear to support it as a means to terminate processing of name=value pairs.

If use of -- is not considered safe, then we can replace env with export and add a semi-colon before the $$upcxx_cmd. This will have exactly the same scope as the current logic, since the ( which begins the snippet in the issue description starts new scope (sub-shell) which ends right after the (elided above) arguments to $$upcxx_cmd.

[Dan Bonachea]

/usr/bin/env --help
Usage: /usr/bin/env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
Set each NAME to VALUE in the environment and run COMMAND.

Mandatory arguments to long options are mandatory for short options too.
  -i, --ignore-environment  start with an empty environment
  -0, --null           end each output line with 0 byte rather than newline
  -u, --unset=NAME     remove variable from the environment
      --help     display this help and exit
      --version  output version information and exit

A mere - implies -i.  If no COMMAND, print the resulting environment.

GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Report env translation bugs to <http://translationproject.org/team/>
For complete documentation, run: info coreutils 'env invocation'

info coreutils actually documents the opposite behavior for --:

In the rare case that a utility contains a '=' in the name, the only way to disambiguate it from a variable assignment is to use an intermediate command for COMMAND, and pass the problematic program name via ARGS. For example, if './prog=' is an executable in the current 'PATH':

 env prog= true # runs 'true', with prog= in environment
 env ./prog= true # runs 'true', with ./prog= in environment
 env -- prog= true # runs 'true', with prog= in environment
 env sh -c '\prog= true' # runs 'prog=' with argument 'true'
 env sh -c 'exec "$@"' sh prog= true # also runs 'prog='

[Paul Hargrove]

@bonachea I don't understand what the "opposite behavior" means above. There is no mention at all of a double hyphen in the --help output you've pasted. What is the opposite of undocumented?
EDIT: Never mind the text above. I eventually realized you meant opposite of my prior assertion that -- ended parsing name=value pairs rather than my initial interpretation as the opposite of the text you had quoted.

The important thing you've added for me is that third example from coreutils which seems to state that double-hyphen is ignore without ending parsing for name=value pairs.

I'll plan to use export and not env ... -- ...

[Paul Hargrove]

I've realized the entire env-v-export question is probably unnecessary.
My current thought is that the "right" fix is to discard use of environment variables in favor of the corresponding command line options to upcxx.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Paul Hargrove]

This is not something we anticipate ever fixing.