Re: gmake-4.2.1 ignores assignment of ARCH on FreeBSD

[Paul Smith]

On Tue, 2017-12-26 at 14:12 -0800, Yuri wrote:
> pstree shows that this is the only instance of gmake in the system. The 
> parent process is BSD make called by framework.

So maybe ARCH is set by BSD make on (one of) its command line(s), then
inherited by GNU make.

> So I am confident that
> 
> 1. ARCH isn't supplied on the command line
> 2. make erroneously reports ARCH as being in the command line.

I'll amend my statement.  GNU make is being invoked _as if_ ARCH is set
on the command line.

That's unquestionably true, as your investigation has proven.

Make tracks what variables were set on the command line through the
MAKEFLAGS environment variable when it is invoked recursively.  So in
addition to variables literally set on the command line, variables set
in the MAKEFLAGS environment variable are also considered to be set on
the command line.

For example:

  $ echo FOO=make | FOO=env MAKEFLAGS=FOO=cmd make -p -f- 2>/dev/null | grep 
-B1 FOO
  # command line
  FOO = cmd
  --
  # automatic
  -*-command-variables-*- := FOO=cmd

Here you can see that I've set FOO=make in the makefile (via the echo),
in the environment via FOO=env, and "on the command line" to FOO=cmd
via the MAKEFLAGS variable.

The result is "FOO = cmd" because the command line takes precedence.

Normally the assignment, parsing, etc. of the MAKEFLAGS variable is
managed by make itself to support recursion.  However, there's no rule
that users can't set MAKEFLAGS directly (even if there were such a
rule, there's no way for make to know the difference).

Further, this handling of the variable assignments in the MAKEFLAGS
environment variable is mandated by the POSIX specification for make. 
As such, I assume that the BSD make program also manages MAKEFLAGS in a
similar way.  This means that GNU make will inherit any command-line
settings of variables that were provided to BSD make, when BSD make
invokes GNU make recursively.

> 3. ARCH does appear in environment at some point in the run. Might be 
> self-set by make.

It's confusing to use the word "environment" here because it's not
clear whether you mean the program's environment (a la environ / getenv
/ putenv, maintained by the system and passed down to forked
processes), or whether you just mean "make's environment" in some
abstract sense to refer to the data make maintains such as variables
etc.

Whether the ARCH variable is set in the program's system environment is
not relevant here, because make does not use that value in any way. 
Make is only using the value of ARCH which was set "in a command line
context" and is being passed down to sub-makes in that context.

In any event, what I'm trying to say is that this is not a bug in GNU
make: it's expected behavior.  If the BSD Ports framework is setting
some variables "as if" they were provided on the command line,
hopefully they have some documentation somewhere which lists which
variables are being set in this way, so that you can avoid using those
variables in your Ports makefiles.