Not all variables that start with '.' are internals,
and unless they are explicitly flagged as internal should go
into .MAKEOVERRIDES
Update varname-dot-makeoverrides to check this.
Also avoid using SCOPE_CMDLINE when ReadOnly will do.
The previous log format "ParseReadLine (%d): '%s'" focused on the
implementation, it was not immediately obvious to a casual reader that
the number in parentheses was the line number. Additionally, having
both a colon and quotes in a log message is uncommon. The quotes have
been added in parse.c 1.127 from 2007-01-01.
The new log format "Parsing line %d: %s" is meant to be easier readable
by humans. The quotes are not needed since ParseReadLine always strips
trailing whitespace, leaving no room for ambiguities. The other log
messages follow common punctuation rules, which makes the beginning of
the line equally unambiguous. Before var.c 1.911 from 2021-04-05,
variable assignments were logged with the format "%s:%s = %s", without a
space after the colon.
For printing the status of a GNode, there was already made_name (now
renamed to GNodeMade_Name), which prints user-friendly text instead of
the bare enum constant names.
To do this change confidently, I first had to demonstrate that the
output really affects something other than just the word "UNMADE". There
had not been a test for that case before, and the test immediately
discovered a bug in the -dg2 and -dg3 options. This bug is one of the
oldest in make, dating back to at least 1993.
Whether in -k mode or not, the exit status tells whether all requested
targets were made or not. If a dependency could not be made, the main
target was not made as well, therefore the exit status must be nonzero
in such a case.
This part of the code lacked proper unit tests until today. The unit
test deptgt-end-fail.mk is compatible with make>=2003 at least, allowing
to compare the output over time.
In 2003, in the ok-ok-ok-ok case, "Making all from all-dep." was printed
twice in a row, for whatever reason ... (40 minutes later) ... If I had
just made the two commands for 'all' and '.END' more distinguishable.
Back in 2003, the local variables for .END had not been initialized,
instead the .END node was run with the local variables of the last
preceding node. In this case, that node was 'all', therefore ${.TARGET}
had obviously expanded to 'all'.
Somewhere in 2004, the shell commands were no longer run with the -e
flag, which resulted in the "exit status $?" line to be printed in cases
that had stopped early before.
Somewhere in 2005, the local variables for the .END node had been fixed.
The variable ${.TARGET} now had the value '.END', just as expected. In
addition, the dependencies for the .END node were made, although without
getting their proper local variables. This resulted in the output
"Making out of nothing" instead of the expected "Making end-dep out of
nothing".
Still in 2005, in the test case "all=ok all-dep=ok end=ok end-dep=ERR",
the error code of the failed 'end-dep' was first reported as "*** Error
code 1 (continuing)". To compensate for this improvement, a new bug had
been introduced. The test case "all=ok all-dep=ok end=ERR end-dep=ERR"
had properly exited with status 1 on 2005-01-01, but on 2006-01-01 it
exited with status 0, thereby ignoring errors in the .END node.
Somewhere in 2008, some of the error messages (but not all) were
directed to stderr instead of stdout. The actual output stayed the same
though.
Somewhere in 2011, the dependency of the .END node got its own local
variables, and ${.TARGET} now expanded to 'end-dep', as expected.
Somewhere in 2016, the two empty lines between the "*** Error code 1
(continuing)" and the "Stop." got compressed into a single empty line.
On 2020-12-07 (that is, today), the exit status 1 has been restored in
the error cases, after it had been wrong for at least 14 years.
The previous output format had a %-20s conversion specifier. This
produced different output depending on the length of the pathname, which
was too difficult to normalize. By moving the directory name to the
end, it is no longer necessary to fill up any space, and the numbers are
always aligned properly.
As a result, 3 of the unit tests no longer need any special
postprocessing of their output.
sjg