| Age | Commit message (Collapse) | Author |
|
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.
|
|
No functional change.
|
|
No functional change.
|
|
This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.
The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.
There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.
No functional change.
|
|
The name 'NONE' described the bit pattern, which was not useful to
understand its meaning. Omitting VARE_WANTRES only parses the
expression, without evaluating any part of it.
No functional change, not even in debug mode since Enum_FlagsToString
always returns "none" for all-bits-unset.
|
|
These variables all belong to a string variable. Connect them using
FStr, which reduces the number of variables to keep track of.
No functional change.
|
|
|
|
This change provides for a more natural reading order in the code.
Placing the scope first makes it immediately clear in which context the
remaining parameters are interpreted.
No functional change.
|
|
|
|
This continues the previous commit, in which VAR_GLOBAL, VAR_INTERNAL
and VAR_CMDLINE were renamed.
Renaming the variable 'ctxt' was trivial since that word is used nowhere
else. In the comments though, each occurrence of the word 'context' had
to be checked individually since the word 'context' was not only used
for referring to a variable scope. It is also used to distinguish
different situations where characters are escaped in a certain way
('parsing context') and in a few other expressions.
|
|
The word "context" does not fit perfectly to the variables that are
associate with a GNode, as the context is usually something from the
outside and the variables are more like properties inherent to the
GNode.
The term "global context" fits even less. Since the thing where
variables are looked up is commonly named a scope, use that term
instead.
This commit only renames the global variables VAR_GLOBAL, VAR_INTERNAL
and VAR_CMDLINE, plus a few very closely related comments. These are:
GNode.vars (because of line breaks)
GNode_Free (dito)
varname-make_print_var_on_error.mk
varname-make_print_var_on_error-jobs.mk
The debug message in Var_Stats is left as-is since there is no unit test
for it yet.
The other renamings (variable names "context", "ctxt", as well as
further comments) will be done in a follow-up commit.
|
|
After doing the textual renaming across all files, I added a new
function Var_Set that does not expand the variable name. I then undid
the renaming for all calls where the variable name cannot ever contain a
dollar sign. I omitted the word "Expand" from the textual references in
the unit tests and in the debug logging messages since the focus is
usually on the "Set" part, not on the "Expand".
No functional change.
|
|
Most previous calls to Var_Exists use constant variable names. Only the
two calls in parse.c need to expand the variable name.
It may be a good idea to expand the variable name once in VarAssign_Eval
instead of repeating the expansion in each of its special cases.
No functional change.
|
|
All callers with a variable name that is guaranteed to not contain a
dollar sign have been converted to call Global_Append instead of the
previous Global_AppendExpand. After that, Global_AppendExpand was
unused, therefore it was effectively just renamed.
|
|
The plain Var_Append now does not expand the variable name anymore. It
is used in situations where the variable name is known to not contain a
dollar sign.
This is a preparation for adding Global_Append, corresponding to
Global_AppendExpand.
|
|
|
|
There are many places where global variables are set or appended to. To
reduce clutter and code size, encode the VAR_GLOBAL in the function
name.
The word Expand in the function names says that the variable name is
expanded. In most of the cases, this is not necessary, but there are no
corresponding functions Global_Set or Global_Append yet.
Encoding the information whether the name is expanded or not in the
function name will make inconsistencies obvious in future manual code
reviews. Letting the compiler check this by using different types for
unexpanded and expanded variable names is probably not worth the effort.
There are still a few bugs to be fixed, such as in SetVar, which expands
the variable name twice in a row.
|
|
|
|
|
|
No functional change.
|
|
The previous error message is not easily understandable since it is
missing a crucial detail, the column where the operator is needed.
Without this information, the author of the makefile gets no useful
hint. Furthermore, there are several types of operators in makefiles:
the dependency operators ':', '!', '::',
the variable assignment operators '=', '!=', '+=', '?=', ':=',
the conditional operators '&&', '||', '!',
the comparison operators '==', '!=', '>', '>=', '<', '<='.
This leaves too much ambiguity.
Replace this error message with "Invalid line type", which is more
generic, more accurate and thus less misleading.
|
|
In all cases except one, the boolean argument to Buf_Destroy was
constant. Removing that argument by splitting the function into two
separate functions makes the intention clearer on the call site. It
also removes the possibility for using the return value of Buf_Done,
which would have made no sense.
The function Buf_Done now pairs with Buf_Init, just as in HashTable and
Lst.
Even though Buf_Done is essentially a no-op, it is kept as a function,
both for symmetry with Buf_Init and for clearing the Buffer members
after use (this will be done only in CLEANUP mode, in a follow-up
commit).
|