Some useful primitives: escape (and quoting variables), lastwords (for recursivity)… and files with spaces in them?
Hi, I began, for automatic variables containing only one filename, to put them between simple quotes, and to try to escape my filenames in my makefiles, so that if one day someone tries to use my makefiles for files with special chars in them like spaces or quotes. Also, using quotes is especially useful to get more meaningful errors: for instance, recently, I tried to put together some (probably unrelated) gnustep makefile and the makefile of the first World Wide Web Browser (Nexus), and this line caused the following error (ignoring the existence of --warn-undefined-variables, that isn’t known enough): $(ECHO_NOTHING_RECURSIVE_MAKE)$(MAKE) -f $(MAKEFILE_NAME) --no-print-directory --no-keep-going \ make[1]: --no-print-directory: No such file or directory make[1]: *** No rule to make target '--no-print-directory'. Stop. make: *** [internal-all] Error 2 So before to uglily add “MAKEFILE_NAME = $(lastword $(MAKEFILE_LIST))” in the main makefile, since this variable didn’t exist, -f took “--no-print-directory” as its argument and found this file didn’t exist, while with quote -f would have get its argument, but void, and just said: make: the '-f' option requires a non-empty string argument […] Then I implemented some escape functions to do this more properly, and finding out I had to do it without side effects to get it working anywhere in the makefile (or I would just get a side-effect-only procedure defining a variable), and doing it recursively, I found out I needed some lastwords functions to be to firstword what cdr is to car: #!/usr/bin/make -f none = # escape_spc = $(subst $(none) ,\ ,$(1)) escape_char = $(subst $(1),$(1),$(2)) # I add the right quotes inside comments # so emacs syntax coloring disworks less escape_quot = $(call escape_char,','\'') #' lastwords = $(wordlist 2,$(words $(1)),$(1)) escape_chars = $(if $(1),$(call escape_chars,$(call \ lastwords,$(1)),$(call escape_char,$(firstword $(1)),$(2))),$(2)) # it is important that the escape char (antislash, \) is first, other # wise escapings will be escaped escape = $(call escape_spc,$(call escape_chars,\ & ( ) ; < > ? | \ ' " `,$(1))) #' # same thing all:; echo $(call escape,'zero' (one) & "two" ? `cmd` \o/ |o|) Also I was wondering… would there be some possible mechanism so that a filename with spaces in it might be appropriatedly treated by implicit rules? or is it intrinsic to, say, automatic variables splitting with spaces? PS: the right MIME type for makefiles is text/x-makefile right? because text/plain looks a bit poor and reductive to me… ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Why call is not calling like native primitives? even when var is otherwise undef?
Why not, like in shell, when some function/variable is undefined, call an internal one when defined? What’s the historic reason of this? For instance, if there’s an occurence of $(several words) in the makefile, and the variable “several words” isn’t defined (that’s not a natural thing to do anyway), taking its firstword, and being equivalent to $(call several,words) might improve readability, be simpler, etc. then why not? And then I asked myself, if some functions weren’t deemed useful enough to get integrated as native primitives implemented in C, why do we still need to use the $(call fun,args) syntax when it could be done like shell and decide that any multi-word undefined reference could take its firstword and use it as call does? like if in “$(fun args)”, the variable “fun args” being if not undefinable, at least inaccessible, if the "fun" variable exists, make it equivalent to “$(call fun,args)”? Thank you for your time, hoping my message isn’t too much confuse or disrelevant… ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
-j/-l : minimum of jobs running under max-load with auto = cpu+1 default
Because parallelism is not enough generalized and people don’t seek it enough (make is a good example), I long thought it would be a good thing to have a way to have parallelism activated more easily (or even by default) in make (or manually by automake or anything of this kind), until now I think it is essentially used by people who read on archlinux/gentoo/lfs manuals that “-j +1” is the optimum. Then I discovered --load-average, and I’m asking myself wether the optimum is -j n+1, -l 1.0, or -l n or n+1? For whatever is the actual optimum, wouldn’t be a useful option for portability that make go search the core number in /proc/cpuinfo when available, or anything more lowlevel, simple to parse or portable if possible, and use that as a default if instead of a number the text “auto” is given as an argument to -j or -l? I was also wondering: is this constant number of jobs, with additionally -l 1.0 the actual optimum, or would it be better if it was the minimal number of jobs running while it is below this threshold, or the maximal one, like it is currently? If the former, would it be worth to change the current behavior? I think a such default (and pre-automated) way to call make could maybe incitate people to try using parallelism capabilities of GNU make in automatic build tools so then it’s more used, then more tested, and parallel-compatible makefiles become more common, if they’re not enough already. Sorry for verbosity, I hope a such handencement-request is relevant enough for your time, so thank you in advance! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
$(call x) rebinds the positional parameters. $x and $(x) do not. This distinction is used to break macro logic into smaller pieces in which $1 et al. still refer to the positional parameters from the top-level macro instead of being rebound to the empty string. Kyle On Mon, May 21, 2018, 4:11 AM Garreau, Alexandre wrote: > Why not, like in shell, when some function/variable is undefined, call > an internal one when defined? What’s the historic reason of this? > > For instance, if there’s an occurence of $(several words) in the > makefile, and the variable “several words” isn’t defined (that’s not a > natural thing to do anyway), taking its firstword, and being equivalent > to $(call several,words) might improve readability, be simpler, > etc. then why not? > > And then I asked myself, if some functions weren’t deemed useful enough > to get integrated as native primitives implemented in C, why do we still > need to use the $(call fun,args) syntax when it could be done like shell > and decide that any multi-word undefined reference could take its > firstword and use it as call does? like if in “$(fun args)”, the > variable “fun args” being if not undefinable, at least inaccessible, if > the "fun" variable exists, make it equivalent to “$(call fun,args)”? > > Thank you for your time, hoping my message isn’t too much confuse or > disrelevant… > > ___ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make > ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: -j/-l : minimum of jobs running under max-load with auto = cpu+1 default
On Mon, 2018-05-21 at 08:36 +0200, Garreau, Alexandre wrote: > Then I discovered --load-average, and I’m asking myself wether the > optimum is -j n+1, -l 1.0, or -l n or n+1? IMO, there are too many problems with choosing any value as the default value: * It's not so simple to determine the number of CPUs, portably. * Many makefiles invoke commands that themselves are multi-threaded and for these commands you definitely don't want to choose a -j value with "# of CPUs" parallelism. * Many users of makefiles want to do other things with their systems in addition to builds, and don't want to choose a -j or -l value that makes their system slow or unusable. They'd rather their builds take longer. * There are other metrics besides # of CPUs that need to be taken into consideration; for example memory. I have a build environment which builds 200 different C++ programs, each of which ends up to be 200M or so, and the linker takes huge amounts of memory. If I use -j8 on my 8-core system and the rebuild only needs to re-link, my entire system will hang for many minutes swapping RAM (I can't even move the mouse), even though I have enough CPUs. If I choose -j5 or -j6, it works much better. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
On Mon, 2018-05-21 at 08:20 +0200, Garreau, Alexandre wrote: > For instance, if there’s an occurence of $(several words) in the > makefile, and the variable “several words” isn’t defined (that’s not a > natural thing to do anyway), taking its firstword, and being equivalent > to $(call several,words) might improve readability, be simpler, > etc. then why not? For a long time it was perfectly legal to create variable names that contained whitespace; this would work: some variable = foo all: ; @echo $(some variable) gives you "foo". A few releases ago I made it illegal to create variable names containing spaces so the above makefile no longer works. My intention at that time was to allow a shorthand for "call" such as you suggest, but I haven't made that change yet. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Some useful primitives: escape (and quoting variables), lastwords (for recursivity)… and files with spaces in them?
On Mon, 2018-05-21 at 08:12 +0200, Garreau, Alexandre wrote: > Also I was wondering… would there be some possible mechanism so that > a filename with spaces in it might be appropriatedly treated by > implicit rules? or is it intrinsic to, say, automatic variables > splitting with spaces? This is a long-standing request. It's not simple by any stretch. Huge amounts of code inside make itself, not to mention almost every makefile in existence, make assumptions about whitespace being word separators. There was a long discussion here a few years ago about a new capability for handling special characters in filenames possible, and I have a partial implementation that was not completed, of a possible way to do this. Until something drastic changes in GNU make it's simply not feasible to work with whitespace-containing pathnames. It's best to simply avoid them, rather than spending huge amounts of effort to try to make them work. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
On 2018-05-21 at 10:56, Paul Smith wrote: > On Mon, 2018-05-21 at 08:20 +0200, Garreau, Alexandre wrote: >> For instance, if there’s an occurence of $(several words) in the >> makefile, and the variable “several words” isn’t defined (that’s not a >> natural thing to do anyway), taking its firstword, and being equivalent >> to $(call several,words) might improve readability, be simpler, >> etc. then why not? > > For a long time it was perfectly legal to create variable names that > contained whitespace; this would work: > > some variable = foo > > all: ; @echo $(some variable) > > gives you "foo". A few releases ago I made it illegal to create > variable names containing spaces so the above makefile no longer > works. I already did manage to create one before posting anyway: none = # spc = $(none) # some$(spc)variable = foo all:; echo '$(some variable)' > My intention at that time was to allow a shorthand for "call" such as > you suggest, but I haven't made that change yet. If then it has been planned this way, when might we see a such feature arrive? :D On 2018-05-21 at 07:46, Kyle Rose wrote: > $(call x) rebinds the positional parameters. $x and $(x) do not. This > distinction is used to break macro logic into smaller pieces in which $1 et > al. still refer to the positional parameters from the top-level macro > instead of being rebound to the empty string. My suggestion was for only variable names containing a space, so $(x) would keep legacy behavior, while $(x y) would work as any function call. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Some useful primitives: escape (and quoting variables), lastwords (for recursivity)… and files with spaces in them?
On 2018-05-21 at 11:16, Paul Smith wrote: > On Mon, 2018-05-21 at 08:12 +0200, Garreau, Alexandre wrote: >> Also I was wondering… would there be some possible mechanism so that >> a filename with spaces in it might be appropriatedly treated by >> implicit rules? or is it intrinsic to, say, automatic variables >> splitting with spaces? > > There was a long discussion here a few years ago about a new > capability for handling special characters in filenames possible, and > I have a partial implementation that was not completed, of a possible > way to do this. Really? What possible way? IFS like shell? hardcoded list data structure on which primitives would operate? > Until something drastic changes in GNU make it's simply not feasible to > work with whitespace-containing pathnames. It's best to simply avoid > them, rather than spending huge amounts of effort to try to make them > work. Mmmh, is it so radical? I mean, okay I’d see how, for instance, NUL couldn’t be used if it’s like bash and still used as a string terminator instead of some length attribute, and I understand you can’t splice properly automatic variables values that contain several files, or wildcards make functions, etc… but can’t you manage to use the shell to quote the file names you get, and quote individual file names as I proposed with my functions? Also what I’d like in a standard escape function is that, being shared, it would be more tested, and could be improved in case it’s incorrect so that to fulfill the needed usecase (I only did try all the non-alphabetical ascii characters to see if they were doing errors when unescaped), and being that tested, and giving the impression it is tested or going to be, maybe users would feel more confident of using it, and quoting their variables: the problem here is not only of filenames with spaces, but also of void filenames, for better error detection. Also I noticed recursivity isn’t that natural with make, not without something such as car and cdr: my lastwords function play this role but maybe I’m missing something and most people do it differently… Would you think something like it or that would allow the same things more naturally could go inside make as a new text function? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
On 2018-05-21 at 10:56, Paul Smith wrote: > A few releases ago I made it illegal to create variable names > containing spaces so the above makefile no longer works. My intention > at that time was to allow a shorthand for "call" such as you suggest, > but I haven't made that change yet. Also, your (still unlocalized :/) error message isn’t clear and, at the first time, bugged me wondering if the error really was because I did put a space inside the variable name: “spc-var.mk:3: *** missing separator. Stop.”; wouldn’t “space is not allowed in variable names” or more generally “variable name forbidden token”? What separator is it talking about exactely? The space character? the equal sign? something else I’m not thinking to? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
> > On 2018-05-21 at 07:46, Kyle Rose wrote: > > $(call x) rebinds the positional parameters. $x and $(x) do not. This > > distinction is used to break macro logic into smaller pieces in which $1 > et > > al. still refer to the positional parameters from the top-level macro > > instead of being rebound to the empty string. > > My suggestion was for only variable names containing a space, so $(x) > would keep legacy behavior, while $(x y) would work as any function > call. > > I've had the same thought myself. This would probably work, but it needs to do something consistent and understandable in cases like these: $(fn) <= variable evaluation $(fn literal) <= macro expansion $(fn $x) <= macro expansion, even if $x is empty $(fn ) <= ?? maybe macro expansion? Kyle ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: -j/-l : minimum of jobs running under max-load with auto = cpu+1 default
Le 21/05/2018 à 08h23, Paul Smith a écrit : > On Mon, 2018-05-21 at 08:36 +0200, Garreau, Alexandre wrote: >> Then I discovered --load-average, and I’m asking myself wether the >> optimum is -j n+1, -l 1.0, or -l n or n+1? > IMO, there are too many problems with choosing any value as the default > value: > > * It's not so simple to determine the number of CPUs, portably. To me it looks more like a reason to have a such standardized unique determination process inside make rather one a lot of separated not-fully portable disfunctionnal and sparse ones inside shellscripts or makefiles or automake files. Also useful stuff such as jobs, pipe stuff, signals, aren’t fully portable either in make afaik, so would having this to work, optionally, at list on the handful of most popular platform be that an inacceptable thing? > * Many makefiles invoke commands that themselves are multi-threaded >and for these commands you definitely don't want to choose a -j >value with "# of CPUs" parallelism. That’s what manual specification of jobs numbers is for, I wasn’t speaking about removing it but making it more accessible. > * Many users of makefiles want to do other things with their systems >in addition to builds, and don't want to choose a -j or -l value >that makes their system slow or unusable. They'd rather their >builds take longer. Then maybe some suitable value can at the same time be acceptable while useful to make parallelism more of a standard and tested thing? such as “(min 2 (/ cores 4))”. That could be “auto”, and cores+1 could be “max” or “fullspeed” or something alike. > * There are other metrics besides # of CPUs that need to be taken into >consideration; for example memory. I have a build environment which >builds 200 different C++ programs, each of which ends up to be 200M >or so, and the linker takes huge amounts of memory. If I use -j8 on >my 8-core system and the rebuild only needs to re-link, my entire >system will hang for many minutes swapping RAM (I can't even move >the mouse), even though I have enough CPUs. If I choose -j5 or -j6, >it works much better. It seems to still be a reason to keep that number greater than one but below a given threshold… also make could internally check such things such as memory, without adding the cumbersome of manually checking for available memory, average memory comsuption of process, etc. Ideally users may add memory management options to their kernel/operating system to avoid such inconvenience (afair, but I never got fully to it, under Linux it’s something that deals with ulimits, the same kind of settings that makes forkbombs not killing your system, but maybe kOpenBSD or Hurd have something else more elaborated). And still: you can still specify yourself the numbers of cores if you do something like that (and I guess the discussed option since the beginning here doesn’t imply switching parallelism by default). Also I was suggesting not only to add a default (or several, that may be triggered only by one or several keywords), but also to, when -l is specified, make -j specify minimum jobs rather than maximum jobs running. So -j cores+1 would always keep at least all my cores busy, and would start other ones if that’s not enough because of some other bottleneck (blocking I/O). Or is this actually *strictly* less useful than the current behavior? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
On 2018-05-21 at 12:17, Kyle Rose wrote: >> On 2018-05-21 at 07:46, Kyle Rose wrote: >>> $(call x) rebinds the positional parameters. $x and $(x) do >>> not. This distinction is used to break macro logic into smaller >>> pieces in which $1 et al. still refer to the positional parameters >>> from the top-level macro instead of being rebound to the empty >>> string. >> >> My suggestion was for only variable names containing a space, so $(x) >> would keep legacy behavior, while $(x y) would work as any function >> call. > > I've had the same thought myself. This would probably work, but it needs to > do something consistent and understandable in cases like these: > > $(fn) <= variable evaluation > $(fn literal) <= macro expansion > $(fn $x) <= macro expansion, even if $x is empty > $(fn ) <= ?? maybe macro expansion? I think we should ask Paul how did he see it himself. Personally, following the idea of disallowing variable names with spaces (which aren’t easy creating anymore) $(fn ) would stay a variable evaluation, and either we let $(N) be possibly bound to the void string, possibly allowing to be rebound if used in another macro, either we try to unify something by always binding $(0) to the variable name, but then that would break legacy behavior when you compose a macro from several other macros… ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
On Mon, 2018-05-21 at 18:17 +0200, Garreau, Alexandre wrote: > On 2018-05-21 at 10:56, Paul Smith wrote: > > A few releases ago I made it illegal to create variable names > > containing spaces so the above makefile no longer works. My > > intention at that time was to allow a shorthand for "call" such as > > you suggest, but I haven't made that change yet. > > Also, your (still unlocalized :/) That message is localized. If your localization doesn't support that message, you should report it to the translation team for your language. For all messages in GNU make (and all other GNU and most other GNU/Linux programs) if there is no translation available for a string it falls back to the standard C local string. Contact your translation team here: https://translationproject.org/team/index.html > error message isn’t clear and, at the first time, bugged me wondering > if the error really was because I did put a space inside the variable > name: “spc-var.mk:3: *** missing separator. Stop.”; wouldn’t “space > is not allowed in variable names” or more generally “variable name > forbidden token”? > > What separator is it talking about exactely? The space character? the > equal sign? something else I’m not thinking to? That's exactly the problem. Makefile syntax is actually fairly free- form, so make doesn't know that the line is really intended to be a variable assignment. The only way to know the intent is by locating a separator; until make finds a separator the line is just a list of tokens. It might be intended to be a variable assignment, in which case the separator that's missing is "=": foo = bar = baz Or it might be intended to be a rule, in which case the separator that's missing is ":": foo : bar = baz ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Why call is not calling like native primitives? even when var is otherwise undef?
Le 21/05/2018 à 13h50, Paul Smith a écrit : > On Mon, 2018-05-21 at 18:17 +0200, Garreau, Alexandre wrote: >> On 2018-05-21 at 10:56, Paul Smith wrote: >> > A few releases ago I made it illegal to create variable names >> > containing spaces so the above makefile no longer works. My >> > intention at that time was to allow a shorthand for "call" such as >> > you suggest, but I haven't made that change yet. >> >> Also, your (still unlocalized :/) > > That message is localized. I meant in my language sorry, and in debian, and actually according the project translation page [1] it was only for the version currently shipped in Debian, not the following. >> What separator is it talking about exactely? The space character? the >> equal sign? something else I’m not thinking to? > > That's exactly the problem. Makefile syntax is actually fairly free- > form, so make doesn't know that the line is really intended to be a > variable assignment. The only way to know the intent is by locating a > separator; until make finds a separator the line is just a list of > tokens. > > It might be intended to be a variable assignment, in which case the > separator that's missing is "=": > >foo = bar = baz So you mean before you forbid assignment to variable with space in their names, the separator could be = with a space before it? why don’t having keeped this parsing behavior and then just output an according error in this case? I don’t see the case for multiple words variable names except when planning for named parameters… [1] https://translationproject.org/domain/make.html ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Some useful primitives: escape (and quoting variables), lastwords (for recursivity)… and files with spaces in them?
On Mon, 2018-05-21 at 18:13 +0200, Garreau, Alexandre wrote: > > There was a long discussion here a few years ago about a new > > capability for handling special characters in filenames possible, > > and I have a partial implementation that was not completed, of a > > possible way to do this. > > Really? What possible way? IFS like shell? hardcoded list data > structure on which primitives would operate? The idea was to introduce a new quoting facility that would allow make to store strings internally in such a way that whitespace (and other special characters) wouldn't be considered word separators. Then just before the recipe was sent to the shell, these strings would be re-converted into standard format. It would be the responsibility of recipe writers to ensure that quoting worked properly. The solution only intended to allow make rules and functions to behave properly. > > Until something drastic changes in GNU make it's simply not > > feasible to work with whitespace-containing pathnames. It's best > > to simply avoid them, rather than spending huge amounts of effort > > to try to make them work. > > Mmmh, is it so radical? I mean, okay I’d see how, for instance, NUL > couldn’t be used if it’s like bash and still used as a string > terminator instead of some length attribute, and I understand you > can’t splice properly automatic variables values that contain several > files, or wildcards make functions, etc… but can’t you manage to use > the shell to quote the file names you get, and quote individual file > names as I proposed with my functions? There are a few major issues. First is, as you say, you can't use any make functions or most automatic variables or variations such as $(^D) $(^F) etc. That by itself is enough to make it a non-starter for pretty much every makefile out there. But, in addition how do you create targets or prerequisites with spaces in the name? You can't use magical shell quoting on them, because make looks them up on the filesystem and if you add quoting they won't be found. Also, remember that users can set the make SHELL variable to anything they like: it doesn't have to be a POSIX-y shell. So, we can't automatically assume shell-style quoting rules. We have to leave it up to the user, or at least allow it to be left up to the user. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Pattern matching for static pattern rules
I was running into some behavior that surprised me when using static pattern rules with files in a subdirectory. A fairly minimal case: $ mkdir foo && echo foo/bar > foo/text.bar $ cat Makefile all : foo/text.bar.sha1 foo/text.bar.md5 text.%.sha1 : text.% sha1sum "$<" > "$@" foo/text.bar.md5 : text.%.md5 : text.% md5sum "$<" /dev/null > "$@" $ make Makefile:7: target `foo/text.bar.md5' doesn't match the target pattern sha1sum "foo/text.bar" > "foo/text.bar.sha1" md5sum "" /dev/null > "foo/text.bar.md5" md5sum: : No such file or directory make: *** [foo/text.bar.md5] Error 1 With (implicit) pattern rules, "When the target pattern does not contain a slash (and it usually does not), directory names in the file names are removed from the file name before it is compared with the target prefix and suffix."[1] With static pattern rules, this doesn't seem to be the case. I'm not sure whether this is intentional or not. The documentation seems to suggest that static pattern rules and implicit pattern rules should behave basically equivalently (with respect to pattern-matching file names, at least), claiming that "A static pattern rule has much in common with an implicit rule defined as a pattern rule (see Defining and Redefining Pattern Rules). Both have a pattern for the target and patterns for constructing the names of prerequisites. The difference is in how make decides when the rule applies."[2] It seems like either this is a bug in the code, or something that should be clarified in the documentation as a difference between the two rule types. (I'd imagine this may not have been noticed because in the (common?) case that the pattern is "%something", it doesn't mattern whether the directory is removed first, then the pattern is matched, and finally the directory re-added; or the match is done against the full path. Unfortunately, for my actual case, filenames have a common prefix, not a common suffix.) Thanks, Alex [1] https://www.gnu.org/software/make/manual/html_node/Pattern-Match.html#Pattern-Match [2] https://www.gnu.org/software/make/manual/html_node/Static-versus-Implicit.html#Static-versus-Implicit ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
