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

Follow-up Comment #12, bug #63686 (project make): > Paul, if you decide to do the special target, do you intend to let that special target have prerequisites, e.g. targets for which the feature is enabled? No, the prerequisites of the special target are the warning control options: .WARNINGS:

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

Follow-up Comment #9, bug #63686 (project make): One other thing: obviously a special target can't be in effect until it appears in the makefile, unlike a command line option which is always in effect. That means that if you didn't put that special target right at the top of a given makefile,

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

Follow-up Comment #8, bug #63686 (project make): I'm just trying to be clear about what is available, and the tradeoffs. Maybe some of these are not interesting to consider. There is an argument to be made that requiring every individual makefile to include its own .WARNINGS: special target (or

[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

[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

[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: ___

[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: ___

[bug #63821] Switch -r fails to disable default suffix rules.

Follow-up Comment #8, bug #63821 (project make): Yes I'm going to go through and remove them all as a cleanup, not until after this release though. ___ Reply to this item at:

[bug #63821] Switch -r fails to disable default suffix rules.

Update of bug #63821 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version: SCM => 4.3 Fixed Release:

[bug #63821] Switch -r fails to disable default suffix rules.

Follow-up Comment #4, bug #63821 (project make): Curious why you decided to install the default suffix rules after snap_deps() @dgoncharov . That doesn't feel right to me, was there something that didn't work right if you did it between defining the makeflags and snap_deps(), rather than after?

[bug #63621] Enhancement request - new built in variables

Follow-up Comment #1, bug #63621 (project make): > BTW $(info...) can't be used in the first example as the return is not always 7 bit ASCII. $(info) seems to fail with UTF. "UTF" is not a sufficient specification to understand this problem. GNU make expects makefiles to be encoded in UTF-8

[bug #63737] Add --fail-on-undefined-variables

Update of bug #63737 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi; thanks for the

[bug #63689] Typos

Update of bug #63689 (project make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixed Release:

[bug #63690] temp_stdin and output_sync failure on macos

Update of bug #63690 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63688] Allow env variable AR="ar -X 64"

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

[bug #63667] In POSIX mode, the shell should not be run with -e if errors are ignored

Update of bug #63667 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #63667] In POSIX mode, the shell should not be run with -e if errors are ignored

Follow-up Comment #1, bug #63667 (project make): This is actually a bit tricky. GNU make allows the user to specify their own shell flags, so the real rule is "if the user didn't override the shell flags, AND POSIX is set, AND we're not ignoring errors, then use "-ec" as the shell flags. I have

[bug #63668] Default value of CXX on BSD OS's

Follow-up Comment #2, bug #63668 (project make): I wonder if we shouldn't be using configure to locate the C++ compiler. Of course it could be the case that the compiler is visible at the time make is built but not at the time make is invoked; we wouldn't use the full pathname of course just the

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #21, bug #63307 (project make): This should be fixed in the for the 4.4.1 release; you can download and try a pre-release of it here: https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.gz ___ Reply to this item at:

[bug #63639] Make syntax inconsistencies (perhaps old, no way to tell)

Follow-up Comment #2, bug #63639 (project make): Just to note: # Issue with grouped targets target&: prereqs #is not the same as target &: prereqs #The former works, the latter (with a space) tries to find a prereq called & The comment at the end of this is not correct. In GNU Make 3.81, the

[bug #63639] Make syntax inconsistencies (perhaps old, no way to tell)

Update of bug #63639 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: You are using a

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #6, bug #63650 (project make): I guess we might be saved by a weird behavior of GNU Make that I've long considered changing because it confuses people: when we are about to expand a recipe we expand all lines in the recipe at once, before we invoke the first line. This means

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Update of bug #63650 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #5: What about this idea: we would create a new environment when needed with all variables expanded,

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #4, bug #63650 (project make): I don't think this is a bug. Or, at least I don't think we can fix it. In previous versions of GNU Make we did not add make variables to the environment of the shell function regardless of their export status. So for example this makefile:

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

Follow-up Comment #3, bug #63650 (project make): I think they just mean they also tested Git HEAD (which is the commit mentioned) and see the same behavior as with the GNU Make 4.4 release. ___ Reply to this item at:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #16, bug #63638 (project make): I just mean writing a test that's portable. I can try again hard-coding SHELL and restricting the test to only run on Windows, or something like that. ___ Reply to this item at:

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Update of bug #63638 (project make): Assigned to:None => eliz Triage Status:Verified => Medium Effort ___ Follow-up Comment #14: I made a stab at

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #11, bug #63638 (project make): You definitely should but you'll have to do more debugging, ideally giving a repro case as you did for the PATH issue. It may be challenging: our regression tests for output-sync are not failing so I don't think the problem is obvious. We did

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

Follow-up Comment #4, bug #63638 (project make): Ah, I see. I spent about 30m last night trying to find this but since I don't really do Windows development I was reduced to printf debugging and couldn't come up with it before I had to go to dinner :). That was my fault breaking this. That

[bug #58075] getopt.c: compiler warning: add explicit braces to avoid dangling else

Update of bug #58075 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #17448] Function argument parsing inconsistent in treatment of whitespace

Follow-up Comment #2, bug #17448 (project make): I pushed a fix for the $(file ...) function. The other inconsistencies will need to be dealt with later... I don't want to make backward-incompatible changes right now. ___ Reply to this

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Update of bug #58556 (project make): Component Version:None => 4.2.1 ___ Reply to this item at: ___

[bug #59247] function shell eats a newline

Update of bug #59247 (project make): Item Group:None => Enhancement ___ Reply to this item at: ___

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

Update of bug #60799 (project make): Item Group:None => Enhancement ___ Reply to this item at: ___

[bug #62575] Garbled ANSI color codes in Cygwin mintty

Update of bug #62575 (project make): Item Group:None => Enhancement ___ Reply to this item at: ___

[bug #61218] The -e option confuses the $(origin )

Update of bug #61218 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #62595] Add ability to read .env files into make

Update of bug #62595 (project make): Summary: Add ability to read .env files into make and => Add ability to read .env files into make ___ Reply to this item at:

[bug #30829] vpath conflict with file mention in makefile vs file on disk

Follow-up Comment #1, bug #30829 (project make): I checked this with GNU Make 4.4(.1) and see the same behavior still. In the success case if we add -d and examine the output we get (extracting the interesting bits): Trying pattern rule '%.enu: %.h' with stem 'boo'. Trying implicit

[bug #31248] .SECONDEXPANSION: Inconsistent expansion of glob patterns in pattern rule dependency lines

Follow-up Comment #1, bug #31248 (project make): I've tested this with the latest GNU Make 4.4(.1). I didn't really follow all the discussion of previous behaviors, but here is how things currently behave, which doesn't seem right to me: Given the setup below, when run without second expansion:

[bug #32042] Rules with multiple outputs and intermediate chains

Update of bug #32042 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #32042] Rules with multiple outputs and intermediate chains

Update of bug #32042 (project make): Status:None => Fixed Assigned to:None => psmith Component Version:None => 3.82 Fixed Release:

[bug #62654] Add z/OS support

Update of bug #62654 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #61463] private does not suppress inheritance on exported target specific variables

Update of bug #61463 (project make): Fixed Release: 4.4 => SCM ___ Reply to this item at: ___

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #13, bug #14927 (project make): I don't see the point in that. If you want to do that you should just stop using the special archive features of make and treat it like any other target. The only reason to use the special archive feature is to allow the object files to be

[bug #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

Follow-up Comment #5, bug #16788 (project make): I always do my compilation on Windows using straight MSVC. I don't have any cygwin or mingw compiler installed there. I don't own a license for Windows so I use the developer download to run it in a VM; this expires every 90 days so I only do the

[bug #14927] Fix for building archive members in parallel

Update of bug #14927 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

Update of bug #16788 (project make): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #3: I don't see any

[bug #61463] private does not suppress inheritance on exported target specific variables

Update of bug #61463 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63609] Fix a buffer overrun in warn_undefined.

Update of bug #63609 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #10, bug #14927 (project make): The real question is, should we modify the default rules to allow parallel archive builds to work out of the box? Or should we just make it possible for users to rewrite the rules to allow it if they want to? In order to allow it by default we'd

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #9, bug #14927 (project make): We don't need to worry about shared libraries because make's special syntax only works for archives (created by ar) not for shared libraries, which are constructed like programs (created by the linker). An archive stores a time last modified for

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #7, bug #14927 (project make): I was actually thinking about Reid's original request. I have no problem with using some external tool such as a pseudo filesystem, but that's outside the purview of GNU Make. These days it seems to me that intermediate files are less and less

[bug #15719] Test suite not reliable for parallel build support

Update of bug #15719 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed

[bug #15492] Intermediateness of multiple targets in pattern rules

Update of bug #15492 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #5, bug #14927 (project make): Of course the simplest thing to do is just avoid the library syntax altogether and write the makefile as: SRCS := a.c b.c OBJS := $(SRCS:.c=.o) LIB := mylib.a $(LIB): $(OBJS) ; $(AR) -U cru $@ $? This ensures that we build just object files and

[bug #9063] Need a less-verbose debug mode.

Update of bug #9063 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #17881] Better documentation of make rules

Update of bug #17881 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #17873] .NOTPARALLEL enhancements

Update of bug #17873 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #18995] variable origin changes upon export or unexport

Update of bug #18995 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version:None => 3.81 Fixed Release:

[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug

Update of bug #18396 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #20394] vpath directive drops entries

Update of bug #20394 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #28456] Expansion of $$< is incorrect

Update of bug #28456 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 4.3

[bug #28475] A plugin based architecture for functions

Update of bug #28475 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #27556] no rule to build target via vpath when jobserver is unavailable

Update of bug #27556 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #8035] undefined special variables

Update of bug #8035 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: This was fixed via bug

[bug #61763] [PATCH] glob: Do not use realloc wrapper on FreeBSD

Update of bug #61763 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #62936] Confusing description of chained rules in the manual

Update of bug #62936 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I reread this

[bug #50372] gmk_floc missing offset member

Follow-up Comment #1, bug #50372 (project make): The offset field is not really needed by the load setup function. It only has a value inside a recipe: lineno is the line number of the start of the rule, and offset is the number of lines into the recipe. Since load operations don't appear

[bug #62654] Add z/OS support

Follow-up Comment #7, bug #62654 (project make): Also it appears to be from a build on a GNU/Linux x64 system, not z/OS??? ___ Reply to this item at:

[bug #62654] Add z/OS support

Follow-up Comment #6, bug #62654 (project make): I did get your emails, sorry for not replying Igor. I took a look at the config.log you attached and it appears to be from a different package, not from GNU make, unfortunately. ___ Reply

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #13, bug #63347 (project make): I will add a note to NEWS, thanks for the suggestion Dmitry. ___ Reply to this item at: ___ Message

[bug #58365] make 4.3 segfault on s390x alpine linux

Update of bug #58365 (project make): Status:None => Cannot Fix Open/Closed:Open => Closed ___ Follow-up Comment #2: No more info is

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Update of bug #63439 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #63452] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on MAKECMDGOALS

Update of bug #63452 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #63552] includes specified with -I ignored when -C is also used, since 4.4

Update of bug #63552 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #63552] includes specified with -I ignored when -C is also used, since 4.4

Follow-up Comment #1, bug #63552 (project make): Thanks for the report. I have a fix for this. ___ Reply to this item at: ___ Message sent via

[bug #63537] Regression in switches that can be flipped back and forth.

Update of bug #63537 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #63484] make 4.4 incorrectly thinks target does not exist

Update of bug #63484 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #63516] `include` of absolute path prepends path with `./`

Update of bug #63516 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Update of bug #63510 (project make): Item Group:None => Enhancement Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Follow-up Comment #5, bug #63510 (project make): OK I have a complete fix. ___ Reply to this item at: ___ Message sent via Savannah

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Follow-up Comment #4, bug #63510 (project make): That isn't good enough. I'll look more closely. ___ Reply to this item at: ___ Message sent via

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Follow-up Comment #3, bug #63510 (project make): Actually I probably should spell it out "target is .PHONY" ___ Reply to this item at: ___ Message sent

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Follow-up Comment #2, bug #63510 (project make): I'm not sure if there are other situations where this happens, besides PHONY, but I've applied this patch: diff --git a/src/job.c b/src/job.c index b78f279c..cdca7ce1 100644 --- a/src/job.c +++ b/src/job.c @@ -1893,7 +1893,6 @@ new_job (struct

[bug #63536] Escaping character '#' behavior change since 4.2.1

Update of bug #63536 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Unfortunately

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #9, bug #63516 (project make): > The file name "d:foo" means on Windows "the file 'foo' in the directory that is current on drive 'd' Yep, I don't know much about Windows but I do know that much! :) > So in my opinion we should treat such file names as absolute, because

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #7, bug #63516 (project make): Thanks for the patch but there's no need to spend more time on this; as I said I have a fix. During this time of year I've got a lot going on so it takes me a bit longer to finish things. But Eli I was curious about your comment that we should

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #3, bug #63516 (project make): Yes, that's it. I have a fix and will put in up a patch shortly. ___ Reply to this item at: ___

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #6, bug #63439 (project make): I think it depends a little bit on what you think the goal of the option is. I think that the goal should be to warn when users make use of non-standard variables that are not defined. That is, it's there to catch various typos etc. If that's

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #3, bug #63439 (project make): It's true that the same issue exists for this, but in this case it's not a regression. It also warned in previous releases: ~$ make --version GNU Make 4.3 ~$ echo 'all:;echo $(GNUMAKEFLAGS)' | make -f- --warn-undefined-variables echo ~$ echo

[bug #63362] make 4.4: different behavior with -j1 and -j2 when building manpages from git

Follow-up Comment #7, bug #63362 (project make): I posted a patch for the Git build system to the Git mailing list, to avoid this issue; that change will be needed because the behavior of the Git build system isn't really correct, although prior to 4.4 it was basically ignored. In GNU make 4.4

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

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

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

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

[bug #63429] Escape sequence in logs are lost with -O option

Follow-up Comment #2, bug #63429 (project make): I guess you could also do this in your makefile: grep --color=$(if $(MAKE_TERMOUT),always,auto) foo $< and that should also work. ___ Reply to this item at:

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #10, bug #63347 (project make): The problem in the kernel build system is not related to this change; the issue can also be seen with the released GNU make 4.4 version. For example, set *MAKEFLAGS* like this in your environment before invoking the kernel build: $ export

[bug #63429] Escape sequence in logs are lost with -O option

Update of bug #63429 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: There is no way to

[bug #63373] make 4.4: build failure using AIX XLC 16.1

Update of bug #63373 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #4, bug #63347 (project make): Yes, that's annoying. The problem is that MAKEFLAGS is not fully defined until after all the makefiles are parsed. I remember I changed that as a test last year and something didn't work right, but I can't remember now what it was. Looks like

[bug #63362] make 4.4: different behavior with -j1 and -j2 when building manpages from git

Follow-up Comment #6, bug #63362 (project make): I was able to reproduce this incorrect behavior but haven't had time to look at it closely yet. It's definitely extremely odd. ___ Reply to this item at:

[bug #63373] make 4.4: build failure using AIX XLC 16.1

Follow-up Comment #1, bug #63373 (project make): Strange, I could have sworn I went through all the code and fixed this a few months ago when Dmitry was testing builds on AIX. Will fix, thanks for the report. diff --git a/src/main.c b/src/main.c index 78729de1..ba92de37 100644 --- a/src/main.c

<    1   2   3   4   5   6   7   8   9   10   >