[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #6, bug #63686 (project make): There are a few issues with overriding MAKEFLAGS in the makefile. First, MAKEFLAGS are by definition passed to recursive makes. So if you set an error flag in a parent make, it will be set in the recursive makes as well. It would be difficult to

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #5, bug #63686 (project make): Sorry, previous comment should read "I cannot think of an reason to prefer ...". ___ Reply to this item at: ___

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #4, bug #63686 (project make): I cannot think of an objection to prefer a special target as of current state. At one time manipulating MAKEFLAGS internally was dicey but I gather that as of 4.4.1 it's safe. If so, it appears that the methodologies of "special target with potentia

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #3, bug #63840 (project make): > If you use -r then you've removed all the implicit rules in the makefile, including suffix rules, and so I don't necessarily agree with the idea that even in this case we should still treat these suffixes as special when considering match-anything

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #2, bug #63840 (project make): I'm not sure I get the change suggested. If you use -r then you've removed all the implicit rules in the makefile, including suffix rules, and so I don't necessarily agree with the idea that even in this case we should still treat these suffixes as

[bug #63686] implement a flag to promote make warnings to fatal errors

Update of bug #63686 (project make): Fixed Release:None => SCM ___ Follow-up Comment #3: I have implemented a comprehensive method of controlling warnings in general, including setting the

[bug #63686] implement a flag to promote make warnings to fatal errors

Update of bug #63686 (project make): Component Version: 4.4.1 => 4.0 ___ Reply to this item at: ___ Message

[bug #63840] make allows match-anything rules to match files with the default suffixes

Update of bug #63840 (project make): Component Version: 4.4.1 => 4.4 ___ Reply to this item at: ___ Message

GNU Make 4.4.1 released!

GNU make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. You can learn more at: https://www.gnu.org/software/make/ --

[bug #63840] make allows match-anything rules to match files with the default suffixes

Additional Item Attachment, bug #63840 (project make): File name: sv63840_fix.diff Size:7 KB File name: sv63840_test.diff Size:9 KB

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #1, bug #63840 (project make): When the built-in rules are disabled, make allows match-anything rules to match files with the default suffixes. Example 1 demonstrates how a match-anything pattern rule incorrectly matches a file with the default suffix when the built-in rules are

[bug #63840] make allows match-anything rules to match files with the default suffixes

URL: Summary: make allows match-anything rules to match files with the default suffixes Group: make Submitter: dgoncharov Submitted: Sun 26 Feb 2023 07:59:52 PM UTC Severity:

Re: meaning of # in the variable used as a list of targets

On Sun, Feb 26, 2023 at 01:54:14PM -0500, Paul Smith wrote: > The manual is making this statement because in a define/endef people > use comments without really considering how they are handled so it > seemed prudent to call it out specifically. But the statement made > there is less clear than it

Re: meaning of # in the variable used as a list of targets

On Sun, 2023-02-26 at 19:19 +0100, Arkadiusz Drabczyk wrote: > In the manual it says: > > "Within a @code{define} directive, comments are not ignored during > the definition of the variable, but rather kept intact in the value > of the variable.  When the variable is expanded they will either be >

meaning of # in the variable used as a list of targets

In the manual it says: "Within a @code{define} directive, comments are not ignored during the definition of the variable, but rather kept intact in the value of the variable. When the variable is expanded they will either be treated as @code{make} comments or as recipe text, depending on the cont