| Age | Commit message (Collapse) | Author |
|
No functional change.
|
|
No binary change.
|
|
The variable name '.MAKEOVERRIDES' was already used in the non-macro
form.
No binary change.
|
|
None of the calls to Var_Subst used the return value, and the return
value was always VPR_OK.
No functional change.
|
|
Make variables like .newline and .MAKE.{GID,PID,PPID,UID} read-only.
Reviewed by: rillig
|
|
.SYSPATH: with no sources will clear sysIncPath
otherwise sources are added
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.
|
|
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.
|
|
Document only the POSIX requirement for now, as I didn't find
information about _which_ ancient UNIX systems would corrupt the
filesystem on unlinking a directory.
http://man.cat-v.org/unix-1st/2/sys-unlink (1971) says:
> It is also illegal to unlink a directory (except for the super-user).
https://mail-index.netbsd.org/tech-toolchain/2022/10/06/msg004147.html
|
|
|
|
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.
|
|
No binary change.
|
|
For consistency with the other warnings.
|
|
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.
|
|
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.
|
|
It was wrong of Parse_File to output an unfinished line and hope for
some other code to finish it. As demonstrated in the test, PrintOnError
did not do that in the case of additional debug output.
To keep the overall behavior as close as possible to before, the other
callers of PrintOnError now have to pass the newline themselves. Passing
strings that start with newlines but don't end with them looked
suspicious anyway.
|
|
|
|
Lint will complain about this very soon.
No binary change.
|
|
The latter function already existed in 1993, no idea why it was not
used.
No functional change.
|
|
In meta mode, the affected variable patterns do not contain a '$'.
Outside of meta mode, Global_SetExpand was only called a single time, so
inline that call.
No functional change.
|
|
No functional change.
|
|
This applies to all 4 situations in which the output of an external
command is used for modifying a variable or an expression:
* the assignment operator '!='
* the assignment modifier '::!='
* the SUN shell modifier ':sh'
* the other shell modifier ':!cmd!'
Previously, only the shell modifier ':!cmd!' had debug logging.
Suggested by Christoph Badura.
|
|
This change leaves only literal format strings in parse.c. It allows
for more detailed error messages than the current "non-zero status" or
"exited on a signal".
No functional change.
|
|
No functional change.
|
|
The comment in ApplyDependencySourceOther repeated the code, its second
half didn't match any current code.
The comment above ParseDependencySourcesEmpty repeated the code.
No binary change, except for assertion line numbers.
|
|
Previously, the error message was:
make: (null): file too large
Now it is:
make: (stdin): file too large
|
|
No functional change.
|
|
These types are only needed in the parsing module.
No functional change.
|
|
When make is run without the '-f' option, it searches for the files
'makefile' and 'Makefile' in the current directory. The function
ReadFirstDefaultMakefile allocated memory for these filenames, added the
filenames to opts.makefiles and then freed the memory. From that
moment, opts.makefiles contained dangling pointers.
The function main_CleanUp cleans the list, but only if make is compiled
with -DCLEANUP. Since main.c 1.557 from 2021.12.27.23.11.55, the
strings in opts.makefiles are freed as well, before that, only the list
nodes were freed. Freeing the strings led to the double-free.
Fix this bug by using a separate list for these short-lived strings. At
the point where ReadFirstDefaultMakefile is called, opts.makefiles is
not used anymore, therefore there are no side effects.
To reproduce, run 'make test-coverage', which compiles with -DCLEANUP.
The test opt-chdir failed with a segmentation fault in main_Cleanup.
This test may be the only one that doesn't use the option '-f'.
|
|
No binary change.
|
|
No binary change.
|
|
Renaming savederr to saved_errno makes the comment redundant.
Group the conditions for setting errfmt, retaining their relative order.
No functional change.
|
|
No functional change.
|
|
Since parse.c 1.576 from 2021-12-13 the filenames from opts.makefiles no
longer end up in the GNodes, they are copied by Str_Intern.
|
|
This is a similar pattern as in the other situations where a string is
fed through Var_Subst. In this case though, the unexpanded string may
need to be freed, therefore the FStr_Done that is not needed in the
other places.
No functional change.
|
|
Even though the name of the debug log file currently only occurs in
strings of the form '-dFname' or '-dF+name', the code for replacing '%d'
with the PID accesses the passed string out of bounds. That's not a
problem in practice but looks suspicious anyway.
|
|
Since a non-writable file is not a syntax error, there is no point in
showing the usage in this situation. Showing the usage may have been a
copy-and-paste mistake from a few lines below, when this option was
added back in main.c 1.133 from 2006-10-15.
|
|
No functional change.
|
|
No binary change.
|
|
Breaking out of the first 'for' loop was unnecessarily complicated. The
call to strlen was not necessary since f already pointed at the end of
the string.
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.
|
|
The name eunlink suggested a relation with the similarly named functions
emalloc or esnprintf, but that was misleading. Instead, unlink_file
works like unlink, except that it refuses to remove an empty directory.
No functional change.
|
|
Assisted by indent(1), with manual corrections due to its many remaining
bugs.
No functional change.
|
|
No binary change, except for line numbers in assertions in suff.c.
|
|
It was only used in 2 places, and in both these places, the pointer was
never null.
|
|
Noticed by sjg.
|