[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Follow-up Comment #4, bug #54727 (project make): The first version of the patch is not good, make hangs on this test: $ echo '$(eval all: M:=$$(eval all: Q:=(eval all: T:=M)))' | ./make -f - The second version of the patch takes into account that the target-specific context may already b

Re: [bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

. It seems that it's not hard to fix this bug and the fix does not break existing scripts, I will send a patch when I have time. -michael On Fri, Oct 5, 2018 at 2:50 AM Brian Vandenberg wrote: > On Thu, Oct 4, 2018 at 7:53 AM Michael Builov > wrote: > > > > Foll

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Additional Item Attachment, bug #54727 (project make): File name: make_bug_54727.patch Size:0 KB ___ Reply to this item at: ___ Message sent

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Follow-up Comment #3, bug #54727 (project make): It also possible to step on this "foreach + eval" bug not in a recipe. Please consider the next example: # define global variable f := g # function for defining target-specific variables # $1 - target # $2 - variable def_target_speci

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Follow-up Comment #2, bug #54727 (project make): > By the time we expand the recipe all target-specific variables for that recipe have already been assigned: it's not possible for the recipe to add more target-specific variables to it's target and have those take effect. But this is works: $ ec

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

URL: Summary: foreach variable is not visible for a target specific variable definition in a recipe Project: make Submitted by: mbuilov Submitted on: Tue 25 Sep 2018 02:48:25 PM UTC S

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Follow-up Comment #1, bug #54703 (project make): Hello. This is not a bug. Argument of eval is always expanded prior evalation. Let's see how this works. - ITERATIONS:=1 2 3 ACCUMULATOR:=Macron go home : WORD_1:=Macron WORD_2:=go WORD_3:=home define ACCUMULATE WORD:=$(WORD_$(1)) ACC

[bug #49841] flavor() function incorrectly shows function parameters as defined.

Follow-up Comment #1, bug #49841 (project make): > It appears that the scope of the parameters in the outer function intrudes into the inner function for the flavor() function but not for the value of the parameter. The origin() function is also affected. When inner function takes less argumen

[bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

Follow-up Comment #1, bug #49844 (project make): Hello. There is a bug in your trivial example: 1) 'seq 1000 | xargs -n1000 make -j5' expands to 'make -j5 1 2 3 4 5 6 7 ...' and 2) 'seq 1000 | xargs -n1000 make -j' expands to 'make -j 1 2 3 4 5 6 7 ...' As we can see, in second example '1

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #3, bug #51237 (project make): I have created test application, which detaches console and sleeps for 1000 seconds: #include int main(int argc, char *argv[]) { FreeConsole(); Sleep(100); return 0; } And tested it with this makefile: # run make -j -O, then pres

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #2, bug #51237 (project make): >> ...Would you be willing to assign copyright for your changes to the FSF... Yes, I will, no problem. >> ...signaling the event you added will not interrupt that wait... New event is not supposed to interrupt Main thread waiting for sub-processe

[bug #51237] Deadlock in Ctrl-C handler on Windows

URL: Summary: Deadlock in Ctrl-C handler on Windows Project: make Submitted by: mbuilov Submitted on: Wed 14 Jun 2017 12:43:28 PM UTC Severity: 3 - Normal Item Group: Bug