| Age | Commit message (Collapse) | Author |
|
No binary change.
|
|
This style is used by FreeBSD, among others.
|
|
"looks reasonable" sjg@
|
|
No binary change.
|
|
No functional change.
|
|
No functional change.
|
|
|
|
Since var.c 1.323 from 2020-07-26, modifiers containing unbalanced
braces or parentheses were parsed differently, depending on whether they
were relevant or not.
For example, the expression '${VAR:...}' is enclosed with braces. When
this expression has a modifier ':S,},}},g' that would double each '}' in
that expression, the parser got confused:
If the expression was relevant, the modifier was parsed as usual, taking
into account that the 3 '}' in the modifier are ordinary characters.
If the expression was irrelevant, the parser only counted the '{' and
the '}', without taking into account that a '}' might be escaped by a
'\' or be an ordinary character. Parsing therefore stopped at the first
'}', assuming it would finish the expression '${VAR:S,}'.
This parsing mode of only counting balanced '{' and '}' makes sense for
the modifier ':@var@...@', which expands each word of the expression
using the template from the '...'. These templates tend to be simple
enough that counting the '{' and '}' suffices.
|
|
The variable name '.MAKEOVERRIDES' was already used in the non-macro
form.
No binary change.
|
|
The variable name is distinctive enough to be searched directly in the
code instead of having a named constant for it.
No binary change.
|
|
No functional change.
|
|
None of the calls to Var_Subst used the return value, and the return
value was always VPR_OK.
No functional change.
|
|
No functional change.
|
|
Make variables like .newline and .MAKE.{GID,PID,PPID,UID} read-only.
Reviewed by: rillig
|
|
Reviewed by: rillig
|
|
This fixes the inconsistency of using the macro name in one place and
its value in another place (since 2010).
No binary change.
|
|
As unlink_file is a wrapper around unlink, use the same encoding for the
possible return values as in the wrapped function. This consistency is
more important than expressing all possible return values in the return
type 'bool'.
https://mail-index.netbsd.org/tech-toolchain/2022/10/06/msg004155.html
No functional change.
|
|
The variable cond_min_depth was redundant. It was only accessed while
parsing the makefiles. Merging it into struct IncludedFile removes the
possible confusion between cond_min_depth and including_cond_min_depth.
No functional change.
|
|
The previous names were confusing since they suggested that cond_depth
instead of cond_min_depth would be saved and restored.
No functional change.
|
|
To avoid errors from unclosed conditionals on .break
it is sufficient to just set cond_depth = cond_min_depth.
Patch from rillig
|
|
When .break is encountered within a .for loop
it causes immediate termination.
Outside of a .for loop .break causes a parse error.
Reviewed by: christos
|
|
Determining the location where the error occurred is now done by
ParseVErrorInternal. This frees the remaining code from keeping the
filename and the line number together. It also makes Parse_Error short
enough that it might be worth providing a separate function for each of
the 3 log levels.
No functional change.
|
|
In complex dependency structures, when a build fails, a probable cause
is a missing dependency declaration between some files. In compat mode,
the build order is deterministic, in jobs mode, it is somewhat
deterministic. To explore more edge cases, add the line ".MAKE.MODE +=
randomize-targets" somewhere in the makefile.
Fixes PR bin/45226 by riastradh. Reviewed by christos.
|
|
No functional change.
|
|
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
says that in order to make a makefile POSIX-conforming, its first
non-comment line must be the special dependency line '.POSIX:' without
any source dependencies.
Previously, make switched to POSIX mode even if such a line occurred
anywhere else, which was allowed by POSIX but was deep in the
"unspecified behavior" area. For NetBSD make, there is no big
difference since it doesn't ship any <posix.mk> file, this change mainly
affects the bmake distribution.
Previously, makefiles that contain '.POSIX:' somewhere in the middle
could fail due to <posix.mk> resetting .SUFFIXES, among other things.
Suggested by Simon J. Gerraty, who also reviewed an earlier version of
this change.
|
|
When sorting the words of an expression numerically using the modifier
':On' (added on 2021-07-30), use 64-bit numbers even on 32-bit
platforms. A typical use case is comparing file sizes.
When tracing the execution of jobs, fix an integer overflow after 2038.
32-bit platforms that use a pre-C99 compiler still have this problem.
No change to the test suite since most tests simply skip any potential
differences between 32-bit platforms and 64-bit platforms (see
varmod-order-numeric.mk) or already account for both variants (see
varmod-localtime.mk).
|
|
Do not use inline functions, remove trailing comma in enum declaration,
do not use 'long long' for printing a timestamp. This re-introduces the
Year 2038 Problem for pre-C99 compilers when printing the trace log, but
that is a seldom used feature.
|
|
Previously, some line numbers were stored as signed int while others
were stored as size_t. Since line numbers are never negative, use an
unsigned type. Since the maximum file size for makefiles is 1 GB (see
loadfile), unsigned int is large enough even on 64-bit platforms.
Using a single data types reduces the number of type conversions. Using
unsigned int improves compatibility with C90 (printf %u instead of %zu),
which is needed by bmake, which is derived from usr.bin/make.
No functional change.
|
|
All arguments to DEBUG0 are string literals, and none of them contains a
'%', which makes them safe to pass to printf directly. Any accidental
'%' would be caught by the compiler.
No functional change.
|
|
PrintLocation()
|
|
Print the approximate location based on the last command that has been
defined for the target. It would be possible to get more detailed
location information by counting the number of commands of the target,
but that would get messy due to .USEBEFORE, .USE and .DEFAULT, and
still, this is an edge case, so don't waste too much code for it now.
Having this hint about the location is more helpful than just a plain
"Variable X is recursive" without any further details.
|
|
The only fatal error that occurs while the makefiles are read in is the
one about recursive variables, which didn't give any hint about the
location before.
If a recursive variable is detected while evaluating the commands of a
target to be made, there is no location information, as before.
|
|
No functional change.
|
|
The variable is set in the context of the target.
This syntax has been supported by gmake for ~ever.
If necessary a makefile can set .MAKE.TARGET_LOCAL_VARIABLES=false
to disable this.
Expose GetBooleanExpr so parse.c can use it.
|
|
No functional change.
|
|
None of the directives has an uppercase letter, so there is no need to
test for it.
No functional change.
|
|
Suggested by nia.
https://mail-index.netbsd.org/source-changes-d/2022/01/09/msg013564.html
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
For lines that use backslash continuation, the human-readable line
number does not equal the number of raw lines that have been read from
the file.
The big comment in PrintStackTrace has become outdated, it still
referred to first_lineno. Due to the bugs documented in
opt-debug-parse.mk, that function needs to be redone completely.
No functional change.
|
|
No binary change.
|
|
No binary change.
|
|
No functional change.
|
|
A .USE target is not a candidate, so .USEBEFORE shouldn't either.
Since make.h 1.36 from 2001-07-03. In that commit, OP_USEBEFORE should
have been added to OP_NOTARGET.
|
|
No binary change, except for line numbers in assertions.
|
|
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.
|
|
No functional change.
|
|
Assisted by indent(1), with manual corrections due to its many remaining
bugs.
No functional change.
|
|
|
|
As seen in /usr/share/misc/style.
|