| Age | Commit message (Collapse) | Author |
|
No binary change.
|
|
No binary change.
|
|
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
The idea of that variable was to work on constant strings as far as
possible. For now it just blew up the code unnecessarily.
No binary change.
|
|
No functional change.
|
|
Before 2020, there had been a huge function for parsing a dependency
line, with lots of local variables that were reused for different
purposes. When that function was split up into smaller functions, that
was done mechanically, without eliminating redundant variables.
No functional change.
|
|
The large comment is already explained in the archive module.
|
|
The list is only used when a single target name is parsed, in case the
name contains wildcards. There is no need to keep it any longer or
reuse it.
Clean up outdated and redundant comments.
No functional change.
|
|
No functional change.
|
|
The prefix 'Parse' was ambiguous since it was both the module name and a
verb. Rename those functions that don't actually parse anything.
No functional change.
|
|
The interesting part of the .ORDER constraint is what is made before
what, so reveal this information in the debug log.
The debug output from the test looks a bit strange since it forces
'three' to be made before 'one', but that's because the test exercises
the edge case of introducing a circular dependency.
|
|
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.
|
|
Rename 'spec' to 'special', for consistency with the previous commits.
Rename 'tOp' to 'targetAttr' since it is not an dependency operator like
':', it's an attribute like '.SILENT'.
No binary change, except for the line number of the assertion in line
1618.
|
|
No binary change, except for line numbers in assertions.
|
|
The variable name 'end' suggested pointing to the end of the string, but
instead it pointed to the last possible starting position of the word to
be searched. Remove this possible misunderstanding.
No functional change.
|
|
No binary change.
|
|
Make is supposed to be C90-compatible, and __func__ is from C99.
No functional change.
|
|
|
|
Several years ago, the command line options were individual global
variables. The global variable could therefore not be named 'silent'
since that would have conflicted with local variables of the same name.
After moving the global variable to the namespace 'struct CmdOpts',
there is no conflict anymore.
There doesn't seem to be any risk of naming collisions for the names
'touch' and 'query'.
No functional change.
|
|
Assisted by indent(1), with manual corrections due to its many remaining
bugs.
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
This code is not reached, a line containing only the word "include" is
categorized as error before.
No functional change.
|
|
Assign pairs of variables in a consistent order, as far as possible.
Use string functions instead of raw byte access, to make the code more
human-readable. GCC 10 optimizes the code reasonably.
No functional change.
|
|
At the point where ParseDependencyOp is called, cp is guaranteed to
point to either ':' or '!'.
No functional change.
|
|
The call to Buf_DoneData was useless since ownership of the buffer data
has already been passwed on to loadedfile_create and the local variable
'buf' goes out of scope after that statement.
Except for cleaning up in debug mode, there is no reason to call
Buf_DoneData and then discard the returned value.
No functional change.
|
|
Previously, each time a .for directive pushed its buffer on the input
file stack, the current filename was duplicated. This was a waste of
memory.
The name of a file is typically only used while it is read in. There is
one situation when the filename is needed for longer, which is when a
target is defined.
Since .for loops are implemented as a special form of included files,
each .for loop duplicated the current filename as well.
$ cat << EOF > for.mk
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.endfor
.endfor
.endfor
.endfor
.endfor
.endfor
.endfor
all:
@ps -o rsz -p ${.MAKE.PID}
EOF
$ make-2021.12.13.03.55.16 -r -f for.mk
RSZ
10720
$ ./make -r -f for.mk
RSZ
1716
The difference is 8 MB, which amounts to 1 million .for loops.
|
|
Previously, each .include leaked a copy of the file name.
|
|
The word 'set' sounded too much like it would replace the current file,
but instead the file is pushed to the stack, and the previous file is
continued later.
No functional change.
|
|
|
|
The majority of the existing error messages and warnings does not
include a period at the end. Follow this style consistently.
|
|
|
|
There is no need to load the buf_end from memory each time a character
from a makefile is processed. The end of the buffer only changes when
the file changes, not while reading a single line.
No functional change.
|
|
No functional change.
|
|
The function SetFilenameVars is only called with fixed variable names,
none of which contains a '$', so take a shortcut.
No functional change.
|
|
The string passed to IncludeFile is only used during that function call,
it is not stored anywhere.
No functional change.
|
|
It was confusing to let the variable 'file' point to the '<' of the
.include directive. In each parsing function, there should only be a
single moving pointer, typically named 'p' or historically 'cp', even
though the 'c' is redundant.
No functional change.
|
|
No functional change.
|
|
These were leftovers from earlier refactorings, when extracting code to
separate functions.
No functional change.
|
|
|
|
No functional change.
|
|
The word 'fatals' was an unnecessary abbreviation.
No functional change.
|
|
|
|
|
|
No functional change.
|
|
As was apparent in VarEvalFlags_ToString, a bit-set was not the best
data type since most of the flags were not freely combinable. The two
flags that could be combined were keepDollar and keepUndef, but even
these have distinguished names in the debug log.
The downside of struct bit-fields is that they need extra helper
functions in C90 (see nonints.h). Exchange these for a few helper
functions in var.c, to keep the code outside var.c simple.
No functional change.
|
|
No functional change, except for debug logging.
|
|
These two functions have counterparts that include the word 'Do' in
their name, which is confusing.
No functional change.
|