| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A non-absolute path on an include command is always treated as being
relative to the directory in which "make" was started in, rather than
being relative to the makefile that contains the command. For example,
given the following project structure and file contents:
* Makefile: include src/foo.mk
* src/foo.mk: include bar.mk
* src/bar.mk:
Running "make" on the root project directory (that is, where "Makefile"
is) yields the following:
src/foo.mk:1: bar.mk: No such file or directory
As "bar.mk" in "include bar.mk" is relative to the current (process)
directory (that is, "./bar.mk") and not to where foo.mk is located in
("./src/bar.mk").
So on every makefile that contains an include command, define the root
project directory in the ROOT variable and always include relative to
it, to later enable any included mkfiles to include other mkfiles
without having to worry about the correct path.
Commands used to search and replace:
$ git grep -Flz 'include ../common.mk' -- src |
xargs -0 -I '{}' sh -c \
"printf '%s\n' \"\`sed 's|include ../common.mk|ROOT = ../..\ninclude \$(ROOT)/src/common.mk|' '{}'\`\" >'{}'"
Environment: GNU make 4.3-3.1 on Artix Linux
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As caught by the Clang Static Analyzer:
$ make clean && NO_EXTRA_CFLAGS="yes" scan-build --status-bugs make -C src/fzenity
[...]
main.c:77:10: warning: Value stored to 'ptr' is never read [deadcode.DeadStores]
return ptr++;
^~~~~
1 warning generated.
[...]
scan-build: Analysis run complete.
scan-build: 1 bug found.
The above increment is a no-op, as it is equivalent to
`return ptr; ptr++;`.
For it to make any difference, the prefix increment operator would have
to be used in place of the postfix one:
return ++ptr;
Which would be equivalent to `++ptr; return ptr;`.
But in order to fix the warning (and CI) while avoiding to change the
current behavior, just remove the operator instead.
Added on commit 1cdfa6f95 ("more on firecfg --guide: fzenity",
2022-04-25).
|
Kelvin M. Klann
netblue30