| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the "wildcard" internal functions.
This usage has been present since the first "real" commit in the
repository: commit 137985136 ("Baseline firejail 0.9.28").
> H_FILE_LIST = $(sort $(wildcard *.[h]))
> C_FILE_LIST = $(sort $(wildcard *.c))
There is only a single character (i.e.: "h") inside the character class,
so its usage should make no functional difference. It may stem from a
construct that could have originally looked something like this:
C_FILE_LIST = $(sort $(wildcard *.[ch]))
Which would match both the implementation files and the headers.
From Section 4.4, [Using Wildcard Characters in File Names][1] of the
GNU make manual:
> A single file name can specify many files using wildcard characters.
> The wildcard characters in make are ‘*’, ‘?’ and ‘[…]’, the same as in
> the Bourne shell. For example, *.c specifies a list of all the files
> (in the working directory) whose names end in ‘.c’.
See also Section 2.13, [Pattern Matching Notation][2] of POSIX.1-2017.
Commands used to search, replace and clean up:
$ find . -name .git -prune -o -type f \
\( -name Makefile -o -name Makefile.in \
-o -name '*.mk' -o -name '*.mk.in' \) -print0 |
xargs -0 grep -Fl '$(wildcard *.[h])' | tr '\n' '\000' |
xargs -0 sed -i.bak -e \
's/\$(wildcard \*.\[h\])/$(wildcard *.h)/'
$ find . -name .git -prune -o -type f \
-name '*.bak' -exec rm '{}' +
Note: To make sure that this doesn't actually change anything
functionally, I built firejail-git (AUR) on Artix from master and from
this commit and diffing the resulting files produced no output (other
than showing changes related to the build timestamps).
Misc: Reference to the previous makefile-related changes: commit
2465f9248 ("makefiles: make all, clean and distclean PHONY") /
https://github.com/netblue30/firejail/pull/4024
[1]: https://www.gnu.org/software/make/manual/html_node/Wildcards.html
[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid a stat() call for each affected target and also potentially speed
up parallel builds.
From the GNU make manual[1]:
> Phony targets are also useful in conjunction with recursive
> invocations of make (see Recursive Use of make). In this situation
> the makefile will often contain a variable which lists a number of
> sub-directories to be built.
[...]
> The implicit rule search (see Implicit Rules) is skipped for .PHONY
> targets. This is why declaring a target as .PHONY is good for
> performance, even if you are not worried about the actual file
> existing.
Commands used to search, replace and cleanup:
$ find -type f -name '*Makefile.in' -exec sed -i.bak \
-e 's/^all:/.PHONY: all\nall:/' \
-e 's/^clean:/.PHONY: clean\nclean:/' \
-e 's/^distclean:/.PHONY: distclean\ndistclean:/' '{}' +
$ find -type f -name '*Makefile.in.bak' -exec rm '{}' +
[1]: https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
|
|
|
|
|
|
|
|
| |
With a fun little script:
$ git ls-files -z -- '*Makefile*' |
xargs -0 -I '{}' sh -c \
"test -s '{}' && printf '%s\n' \"\`git stripspace <'{}'\`\" >'{}'"
|
|
|
|
|
|
|
| |
according to GCC documentation (https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html):
"For predictable results, you must also specify the same set of options
used for compilation (-fpie, -fPIE, or model suboptions) when you
specify this linker option."
|
| |
|
| |
|
|
|
|
| |
https://bugs.debian.org/869707
|
| |
|
| |
|
|
|