[bug #66974] Irregular target introduction of unmatched wildcard include

URL: Summary: Irregular target introduction of unmatched wildcard include Group: make Submitter: None Submitted: Tue 01 Apr 2025 08:15:07 PM UTC Severity: 3 - Normal

[bug #66915] Avoid rebuilding existing order-only prerequisites.

URL: Summary: Avoid rebuilding existing order-only prerequisites. Group: make Submitter: dgoncharov Submitted: Sat 15 Mar 2025 12:18:34 PM UTC Severity: 3 - Normal

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Additional Item Attachment, bug #66915 (group make): File name: sv66915.diff Size: 5KiB <https://file.savannah.gnu.org/file/sv66915.diff?file_id=57021> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Sav

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Follow-up Comment #1, bug #66915 (group make): Suggested by Britton Kerin here https://lists.gnu.org/archive/html/bug-make/2025-03/msg6.html. This is an excerpt from that email. "What confuses me is that since the explicitly requested foo exists and isn't out of date with respect

Re: [bug #66870] memory corruption

On Wed, 2025-03-05 at 18:23 -0500, Dmitry Goncharov wrote: > There is a buffer overflow when shellflags contains characters > special to shell, like =. > See https://savannah.gnu.org/bugs/?65588. I got really fed up with the current command line parser and I have a fully-rewritten version that is

[bug #66870] memory corruption

Follow-up Comment #2, bug #66870 (group make): There is a buffer overflow when shellflags contains characters special to shell, like =. See https://savannah.gnu.org/bugs/?65588. ___ Reply to this item at: <https://savannah.gnu.org/b

[bug #66870] memory corruption

Follow-up Comment #1, bug #66870 (group make): To make the crash happen earier and more often, edit src/job.c to make default_shell be really really long (like 70 characters). ___ Reply to this item at: <https://savannah.gnu.org/b

[bug #66870] memory corruption

URL: <https://savannah.gnu.org/bugs/?66870> Summary: memory corruption Group: make Submitter: None Submitted: Wed 05 Mar 2025 01:18:16 AM UTC Severity: 3 - Normal Item Grou

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #6, bug #66500 (group make): [comment #5 comment #5:] > The rule for foo/tar is lacking a recipie. In this case make has no reason to > invalidate the cached mtime of foo/tar. As explained earlier make has no idea > that the recipie for foo touched foo/tar. Any recipi

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #5, bug #66500 (group make): The rule for foo/tar is lacking a recipie. In this case make has no reason to invalidate the cached mtime of foo/tar. As explained earlier make has no idea that the recipie for foo touched foo/tar. Any recipie for foo/tar, even a empty one, is

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #4, bug #66500 (group make): [comment #3 comment #3:] > This statement applies as make is traversing the graph and is considering a > target. When make is considering baz foo/tar exists and is older. > This is the typical issue when a recipie builds something o

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #3, bug #66500 (group make): This statement applies as make is traversing the graph and is considering a target. When make is considering baz foo/tar exists and is older. This is the typical issue when a recipie builds something other than

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #2, bug #66500 (group make): "Make has no idea that the recipe touched foo/tar." And this is the problem. The manual says: "The recompilation must be done if the source file, or any of the header files named as prerequisites, is more recent than the object

[bug #66237] Grouped target dependencies don't function properly in dry-run mode

Follow-up Comment #1, bug #66237 (group make): I can reproduce this with make-4.3, however, the latest make build from master behaves correctly here. $ make --version GNU Make 4.4.90 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #1, bug #66500 (group make): There is this makefile in the attachment. baz: foo/tar touch baz foo/tar: foo foo: bar -mkdir foo touch foo/tar Make is correct. Make is doing what this makefile tells make to do. The user touches bar and runs make. Make goes through

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #7, bug #66743 (group make): Yes, something must be using MAKE=make or something like that, either in the environment or command line. Make itself never resets the MAKE variable, if it's already set (as far as I&#x

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #6, bug #66743 (group make): > I believe if you invoke it as /home/buildroot/make it will be preserved, > including the full path, and if you invoke it as make it will use that > instead. I'm invoking the make binary with the absolute path at /home/buildroot/

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #5, bug #66743 (group make): [comment #3 comment #3:] > is it expected that it is the same version of make as was executed at the top > level? By default, it's the same as the make that was invoked at the top-level, as documented [https://www.gnu.org/software/

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #4, bug #66743 (group make): GNU Make sets the MAKE variable to whatever the command line invocation of make was. I believe if you invoke it as */home/buildroot/make* it will be preserved, including the full path, and if you invoke it as *make* it will use that instead

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #3, bug #66743 (group make): Ah, it does work if I run the build like this: PATH=/home/buildroot/make:$PATH make host-libxml-parser-perl -j2 --shuffle=reverse Is it expected that when invoking a sub-make as is being done [https://github.com/buildroot/buildroot/blob

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #2, bug #66743 (group make): This fails with GNU Make 4.3 because it doesn't support the FIFO-based jobserver. If you don't want to try to debug it, your other option is to add the *--jobserver-style=pipe* to your top-level make invocation. That will force the e

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #1, bug #66743 (group make): That error message with the "internal error:" prefix was only ever printed by GNU Make 4.3. It's no longer generated by GNU Make 4.4.1. There is a similar error, but it doesn't use the "internal error:" prefix. So, I

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

07:13:43 PM UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: POSIX-Based

[bug #66665] Prefix character not applied to all canned recipe lines if provided by variable

verity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: POSIX-Based Fixed Release

[bug #66658] GNU make should show features with --version

Follow-up Comment #2, bug #66658 (group make): For the short term you can use: echo '$(info $(.FEATURES))' | make -f- 2>/dev/null (the redirect is to avoid the "make: *** No targets. Stop" message. ___ Reply to

[bug #66658] GNU make should show features with --version

Follow-up Comment #1, bug #66658 (group make): Suggestion is by Basile Starynkevitch (France) working on https://github.com/RefPerSys/RefPerSys/ (GPLv3 inference engine for Linux) ___ Reply to this item at: <https://savannah.gnu.

[bug #66658] GNU make should show features with --version

URL: Summary: GNU make should show features with --version Group: make Submitter: None Submitted: Mon 13 Jan 2025 11:05:11 AM UTC Severity: 3 - Normal Item Group

[bug #66627] A target-specific variable side-effect on eval

Follow-up Comment #1, bug #66627 (group make): I forgot to register before posting this bug report. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66627> ___ Message se

[bug #66627] A target-specific variable side-effect on eval

Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: Any Fixed Release: None Triage Status

Re: Bug in GNU make if -j used with very high values

On Wed, 2024-12-18 at 15:29 -0500, Dianne Skoll wrote: > On Debian GNU/Linux 12 with default settings, the command: > >    make -j 7 > > hangs. This is https://savannah.gnu.org/bugs/index.php?66499

Bug in GNU make if -j used with very high values

emaphore. Yes, I realize this is a ridiculous edge-case, but I think it's still technically a bug. Regards, Dianne.

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #10, bug #66499 (group make): Sounds like you had to do some investigation. Thank you for your report. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #9, bug #66499 (group make): Sure! I was testing a patch for gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114542) regarding the -flto= option. When testing edge cases for , I found gcc hanging, which was caused by a blocked GNUmake child process. Of course these values

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #8, bug #66499 (group make): Thanks for review, Paul. Heiko, do you mind sharing the scenario that causes you to specify such high value of jobs? ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66

[bug #66324] Typo in documentation?

Update of bug #66324 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:None => Any F

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Update of bug #66499 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:None => M

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #6, bug #66499 (group make): Thanks a lot for a quick fix! ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66499> ___ Message sent via Savannah

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #5, bug #66499 (group make): Tested on sun 64 and 32 bits and linux 64 and 32 bits. Here is an example $ ls makefile $ cat makefile all:; $(info hello, world) $ make -j68 make: warning: number of jobs is limited to 16384 hello, world make: 'all' is up to da

[bug #66490] Documentation of patsubst function could be more clear

Update of bug #66490 (group make): Item Group: Bug => Documentation Status: Not A Bug => None Open/Closed: Closed => Open Summary: pattern substitution with % does not match

[bug #66490] pattern substitution with % does not match suffixes

Follow-up Comment #3, bug #66490 (group make): Hi, Thanks for the explanations about how this is the intended result. However the reason I created a bug report is that I think in that case the documentation deserves some clarification. > a pattern match means: the "%" match

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #4, bug #66499 (group make): Patch sv66499.diff in the attachment sets the write side of the pipe to non blocking mode and keeps writing until EAGAIN. Tested on linux 64 bit. i am going to test on solaris and report later. (file #56663

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 2024-12-01 at 17:12 +0100, Henrik Carlqvist wrote: > On Sun,  1 Dec 2024 09:10:04 -0500 (EST) > "Paul D. Smith" wrote: > > F_GETPIPE_SZ will work on Linux but it's not portable (not part of > > POSIX > > fcntl) > > Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, > use

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 1 Dec 2024 09:10:04 -0500 (EST) "Paul D. Smith" wrote: > F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX > fcntl) Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, use some arbitrary big value which usually will be "big enough with a margin". I

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #3, bug #66499 (group make): F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX fcntl) ___ Reply to this item at: <https://savannah.gnu.org/bug

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #2, bug #66499 (group make): > Unfortunately I know of no way to determine how large a pipe a system > supports short of filling one up. What about fcntl with F_GETPIPE_SZ? ___ Reply to this item at:

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #1, bug #66499 (group make): The problem is that we are trying to write that many tokens into the jobserver pipe, and it's hanging because there is nothing reading from the pipe. The number of jobs that can be managed depends on how large a pipe the system sup

[bug #66500] Caching of timestamps prevents proper builds

Additional Item Attachment, bug #66500 (group make): File name: makefile Size: 74B <https://file.savannah.gnu.org/file/makefile?file_id=56658> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

[bug #66500] Caching of timestamps prevents proper builds

URL: Summary: Caching of timestamps prevents proper builds Group: make Submitter: gwj Submitted: Sat 30 Nov 2024 03:15:29 PM UTC Severity: 3 - Normal Item Group:

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

ity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: POSIX-Based Fixed Release

[bug #66490] pattern substitution with % does not match suffixes

Update of bug #66490 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: To add to what Dmitry says: a pattern match mean

[bug #66490] pattern substitution with % does not match suffixes

Follow-up Comment #1, bug #66490 (group make): In the case of patsubst pattern '.%' does not match input 'bcd.efg'. Same for substitution references. Try something like $(patsubst %.efg,%,$(A)) or B:=$(A:.efg=) ___ R

[bug #66490] pattern substitution with % does not match suffixes

Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.3 Operating System: POSIX-Based Fixed Release: None Triage Status

[bug #66424] Infinite loop when cross-compiling glibc-2.12.2

Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: Any Fixed Release: None Triage Status

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #2, bug #66381 (group make): The proposed patch will not work well on MS-Windows: it assumes that '/' is the only possible directory separator character, and it ignores the possibility of a drive letter in file names. I hope these non-portable aspects will be fixed b

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Additional Item Attachment, bug #66381 (group make): File name: sv66381_split_stem.diffSize: 50KiB <https://file.savannah.gnu.org/file/sv66381_split_stem.diff?file_id=56575> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source c

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #1, bug #66381 (group make): This commit introduces two user visible changes. 1. Split the stem for static pattern rules to dirname and basename. With this feature static pattern rules do the same stem splitting and directory prefix reconstruction as implicit search does for

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

URL: Summary: Stem splitting and directory prefix reconstruction for static pattern rules. Group: make Submitter: dgoncharov Submitted: Sat 26 Oct 2024 08:38:30 PM UTC Severit

[bug #57962] make attempts to execute a directory found on PATH

Update of bug #57962 (group make): Fixed Release:None => 4.4 ___ Reply to this item at: <https://savannah.gnu.org/bugs/?57962> __

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Update of bug #66359 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Marti

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Follow-up Comment #1, bug #66359 (group make): https://www.gnu.org/software/make/manual/html_node/Makefile-Names.html documents which names are looked for by default. Makefile.mak isn’t one of them. That suggests that the content is unlikely to have been created for use with Gnu Make, so I wish

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: MS Windows Fixed Release: None

[bug #66343] building with -Wstring-compare triggers severe warnings

Follow-up Comment #1, bug #66343 (group make): These seem to be generated by using the streq() macro: /* Test if two strings are equal. Is this worthwhile? Should be profiled. */ #define streq(a, b) \ ((a) == (b) || \ (*(a) == *(b) && (*(a) == '\0' || !strcmp ((a) + 1

[bug #66343] building with -Wstring-compare triggers severe warnings

URL: Summary: building with -Wstring-compare triggers severe warnings Group: make Submitter: None Submitted: Thu 17 Oct 2024 11:10:41 AM UTC Severity: 3 - Normal

[bug #63016] Recursive variable references itself (eventually) when exporting to $(shell)

Follow-up Comment #2, bug #63016 (group make): I may come to regret posting this, as the current git code is working well for me here. I did ask for this change. That's why I feel duty-bound to report that it bit me today. martind@stormy:~/tmp/D160959$ cat Makefile generate = $(or $(1),$

[bug #66324] Typo in documentation?

URL: Summary: Typo in documentation? Group: make Submitter: None Submitted: Fri 11 Oct 2024 04:05:25 PM UTC Severity: 3 - Normal Item Group: Documentation

[bug #65759] handling of "-" and "--" on command line

Update of bug #65759 (group make): Item Group: Bug => Documentation Status:None => Fixed Assigned to:None => psmith Op

[bug #65777] add const misc global RO arrays

Update of bug #65777 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Update of bug #66268 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #66273] An explicitly mentioned file is not intermediate.

Update of bug #66273 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #6, bug #65588 (group make): [comment #5 comment #5:] > I am experiencing a situation with GNU Make 4.4.1 that is I expect will be resolved with the changes under consideration. i expect the same. > Can you possibly advise me how I can test it in my environment. I will

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #5, bug #65588 (group make): I am experiencing a situation with GNU Make 4.4.1 that is I expect will be resolved with the changes under consideration. Can you possibly advise me how I can test it in my environment. I will build make if needed. In the following 4 one-liners

[bug #66273] An explicitly mentioned file is not intermediate.

Additional Item Attachment, bug #66273 (group make): File name: sv66273_explicit_file_with_double_colon.diff Size: 3KiB <https://file.savannah.gnu.org/file/sv66273_explicit_file_with_double_colon.diff?file_id=56466> AGPL NOTICE These attachments are served by Savane. You can do

[bug #66273] An explicitly mentioned file is not intermediate.

Follow-up Comment #1, bug #66273 (group make): Make incorrectly considers an explicitly mentioned file intermediate when the file is a target of a double colon rule. $ ls makefile $ cat makefile hello.x: %.x: %.q; $(info $@ from $<) hello.q::; touch $@ $ # this is make built from master $

[bug #66273] An explicitly mentioned file is not intermediate.

Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: None Fixed Release: None Triage Status

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Additional Item Attachment, bug #66268 (group make): File name: sv66268_intermfile_removal_error_msg.diff Size: 2KiB <https://file.savannah.gnu.org/file/sv66268_intermfile_removal_error_msg.diff?file_id=56464> AGPL NOTICE These attachments are served by Savane. You can downlo

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Follow-up Comment #1, bug #66268 (group make): Messed up error message about a failure to remove an intermediate file. $ cat makefile all: hello.x %.x: b/%.q; $(info $@ from $<) b/%.q:; mkdir b; touch $@; chmod -w b $ make mkdir b; touch b/hello.q; chmod -w b hello.x from b/hello.q r

[bug #66268] Messed up error message about a failure to remove an intermediate file.

ity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: None Fixed Release

[bug #66237] Grouped target dependencies don't function properly in dry-run mode

an target 'obj2'. Must remake target 'obj2'. touch obj2 Successfully remade target file 'obj2'. It feels to me that in the `&:` case, it's failing to remember that it's fake-built `obj1` when looking

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #5, bug #65908 (group make): [comment #4 comment #4:] > > it would be better that make provides the infos about that line not mis-matched `endif'. > > Sorry but I don't understand what you mean by "that line". Which line is it that make sho

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Update of bug #65908 (group make): Item Group: Bug => Enhancement ___ Follow-up Comment #4: > it would be better that make provides the infos about that line not mis-matched `endif&#x

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #4, bug #66073 (group make): > Maybe the comment intended to use "foo.r" instead? Right, I meant "foo.r" instead of "foo.q". Sorry for confusion. > For example if I use the original description and touch foo.p / bar.p first, then I s

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #3, bug #66073 (group make): I don't understand why the previous comment is talking about foo.q. In what way would it ever be correct for foo.q to appear in "$?"? foo.q is one of the targets and "$?" lists the out of date prerequisites. Maybe th

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #2, bug #66073 (group make): I am interested in this topic because this affects Linux kernel build system (Kbuild). If foo.q does not appear in $?, I do not know how to make the combination of if_changed and the grouped target working. foo.p foo.q &: foo.r FORCE $(

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #1, bug #66073 (group make): A user reported an issue here https://lists.gnu.org/archive/html/help-make/2024-08/msg1.html. Here is a copy of that email which contains a good description of the issue. Hi. I have two similar Makefiles. [Makefile1] .PHONY: all all

[bug #66073] $? is set incorrectly in the case of grouped targets.

Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: None Fixed Release: None Triage Status

[bug #66050] add option --shuffle=nosort

Follow-up Comment #3, bug #66050 (group make): I am not a fan having the --shuffle argument modify the behavior of $(wildcard ...) as they are completely disjoint facilities that have nothing to do with each other. IMO it will be confusing. The result of wildcard has swung back and forth

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Update of bug #65739 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None

[bug #66030] --trace only shows the "primary" ($@) target

Update of bug #66030 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Update of bug #66037 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #66018] Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-]

Update of bug #66018 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixe

[bug #65999] make -d could be more descriptive WRT phony targets

Update of bug #65999 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #65982] make --trace does not explain remade include files

Update of bug #65982 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

Update of bug #65917 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixe

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #5, bug #66030 (group make): You are talking about what make knows and what, of the things it knows, it should print in this situation. I don't disagree with any of that. I'm talking about what make _actually does today_. There can be no disagreement about that, sin

[bug #66050] add option --shuffle=nosort

Follow-up Comment #2, bug #66050 (group make): > Are you suggesting a way to always build prerequisites > in an order sorted by their name? The opposite: build *WILDCARD* prerequisites in an order *NOT* sorted by their name. $ touch {a..z} # Current: $ make -E "all: *; @echo $^&quo

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #4, bug #66030 (group make): I'm not trying to be argumentative, really, but I still feel like we're not quite coming to closure on the same topic so let me try one more time. It seems to me there's a significant difference between these two rules: foo.h

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #3, bug #66030 (group make): I think we are just disagreeing over a matter of technical semantics. Make is showing the target it is currently considering, and which it determined to be out of date and so forced make to run the recipe. In your example, that target is "

[bug #65999] make -d could be more descriptive WRT phony targets

Update of bug #65999 (group make): Summary: make --debug=makefile could be more descriptive => make -d could be more descriptive WRT phony targets ___ Reply to this item at: <https://savannah.gnu.org/bugs/

[bug #65999] make --debug=makefile could be more descriptive

Follow-up Comment #1, bug #65999 (group make): Whether or not you specify "makefile" is not relevant for this issue; these messages are printed while building the normal targets. In fact they're printed even with "basic" debug level. However they can b

[bug #66050] add option --shuffle=nosort

Follow-up Comment #1, bug #66050 (group make): I'm sorry but I don't understand this issue. Can you clarify? I don't know what the --shuffle option has to do with sorting: shuffled prerequisites are never sorted (that would go against the entire concept). Are you suggesting

  1   2   3   4   5   6   7   8   9   10   >