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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
