[bug #64016] Simplify update_goal_chain.

Follow-up Comment #2, bug #64016 (project make): I installed the code cleanup, thanks. I don't understand the test that was added though. How does this test show that both rules are run at the same time? It seems like it would behave the same even if they were not. Don't you mean something lik

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

Follow-up Comment #2, bug #64107 (project make): This is a good change, thanks! ___ Reply to this item at: ___ Message sent via Savannah https://savanna

[bug #64124] Use after free in expand_variable_buf.

Update of bug #64124 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

Update of bug #64115 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

Update of bug #64107 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #64016] Simplify update_goal_chain.

Update of bug #64016 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #63868] Document MAKEFLAGS pitfalls.

Update of bug #63868 (project make): Summary: Document MAKEFLASG pitfalls. => Document MAKEFLAGS pitfalls. ___ Reply to this item at: _

Re: [PATCH] Use UTF-8 active code page for Windows host.

On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > I agree with the list.  As for Basic.mk, we can forget about it from > my POV.  Paul should make the call, but from my POV that file was > unmaintained and therefore unsupported. Why do we think it's unmaintained / unsupported? It worked t

Re: [PATCH] Use UTF-8 active code page for Windows host.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 30 Apr 2023 09:55:55 -0400 > > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote: > > I agree with the list.  As for Basic.mk, we can forget about it from > > my POV.  Paul should make the call, but from my POV that file was > > unmainta

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

URL: Summary: Using $(filter ...) on a variable with a large number of words causes seg fault Group: make Submitter: None Submitted: Sun 30 Apr 2023 07:46:59 PM UTC Severity:

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

Follow-up Comment #1, bug #64129 (project make): This was my submission if anyone wants to contact me about it, sorry for submitting anonymously. I thought the site would ask my information at a later step. ___ Reply to this item at:

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

Follow-up Comment #2, bug #64129 (project make): Problem reproduced in 4.3, as claimed in OP. Problem not reproduced in 3.81, 4.1, 4.2.1, 4.3.90, 4.3.91, 4.3.92, 4.4.0.90, 4.4.0.91, 4.4.90 (today's code). Stack trace: In 4.3: (gdb) bt #0 0x5556828d in func_filter_filterout (o=0x55

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

Follow-up Comment #3, bug #64129 (project make): Thanks for your help! I'll look into upgrading. ___ Reply to this item at: ___ Message sent via Savanna

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #4, bug #64016 (project make): [comment #2 comment #2:] > I don't understand the test that was added though. How does this test show that both rules are run at the same time? It seems like it would behave the same even if they were not. Indeed. My test was lacking necessary sy

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #5, bug #64016 (project make): This made me think, why don't we also test the opposite situation? That's that in the sequential mode make does not advance to the next target, until the current target is finished. diff --git a/tests/scripts/features/double_colon b/tests/scripts/

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

Update of bug #64129 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: Duplicate of bug #5909