[bug #63359] patsubst messes up functions in replacement

2022-11-13 Thread Robert Sachunsky
Follow-up Comment #4, bug #63359 (project make): Yes, I am doing that now, plus the outer $(notdir ...). Yes, I must admit the Github experience spoiled me in that regard, but I shall go ML first next time I get lost in make-space so bad I get to believe it's an actual bug (as if that was so easy

[bug #63359] patsubst messes up functions in replacement

2022-11-13 Thread Robert Sachunsky
Follow-up Comment #2, bug #63359 (project make): Duh, that was stupid of me to think! Sorry to bother you, and thanks for the explanation, anyway! > Instead, you want to apply the function to the `$(FOO)` variable, like this: Yes, but I wanted to avoid that because the pattern … $(notdir $(

[bug #63359] patsubst messes up functions in replacement

2022-11-13 Thread Robert Sachunsky
: None ___ Follow-up Comments: --- Date: Sun 13 Nov 2022 05:30:38 PM UTC By: Robert Sachunsky Consider the following Makefile: FOO = a/b/c $(info $(patsubst %/c,%,$(FOO))) $(info $(patsub

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

2021-06-27 Thread Robert Sachunsky
Follow-up Comment #9, bug #44853 (project make): related/duplicate: #45763 I would like to add that (to my surprise) even the workaround offered by the file function (and specifically documented for this purpose in section 8.6 of the manual, with example recipes) _may not work_: program: $(

[bug #56446] Make shouldn't be running eval when expanding variables for export

2020-08-20 Thread Robert Sachunsky
Follow-up Comment #1, bug #56446 (project make): Yes, _.EXPORT_ALL_VARIABLES_ should at least be *documented* for its danger regarding (forced) early expansion with the very first recipe being executed. This also breaks most usage of functions like _error_ in variables. As for this example, at le

[bug #57692] Parallel make doesn't work well with grouped targets

2020-05-11 Thread Robert Sachunsky
Follow-up Comment #4, bug #57692 (project make): > There is a token in .FEATURES for this capability already Oh, pardon me, I accidentally took an old version for testing. > Notice *groupd-target* here. Splendid! Would you care for a patch/PR of the manual explaining this, with an example (alo

[bug #57898] Automatic variable for all targets on grouped target

2020-05-10 Thread Robert Sachunsky
Follow-up Comment #1, bug #57898 (project make): *$?* is of course already taken (for the update-triggering prerequisites). But I would also find it very useful to have an automatic variable for all the targets in the group. How about *$%* (archive member name) then? The documentation says it's

[bug #57692] Parallel make doesn't work well with grouped targets

2020-05-10 Thread Robert Sachunsky
Follow-up Comment #2, bug #57692 (project make): Still, I believe this new syntax should really be listed in *.FEATURES* That way, makefiles which want to employ this (highly valued!) new feature, can be written in a way that older versions of make can still run them. The documentation should al