[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 #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 #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 #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 #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 #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 #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 #62575] Garbled ANSI color codes in Cygwin mintty

Update of bug #62575 (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 #59247] function shell eats a newline

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

Re: GNUmake v4.4 port on Solaris with gcc 9.5.0

On Thu, 2022-11-03 at 06:57 +0100, Christian Jullien wrote: > Here is the correct one for make v4.4 on Solaris 10 with gcc 9.5.0: > > gcc -c -o libgnu_a-concat-filename.o concat-filename.c > concat-filename.c: In function 'concatenated_filename': > concat-filename.c:69:7: warning: implicit

[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

Re: [PATCH 0/8] Fix compilation on OS/2

On Sun, 2022-11-20 at 23:42 +0900, KO Myung-Hun wrote: > These patches fix compilation on OS/2. I have applied some of these patches as-is, and modified others, but I believe all the changes needed have been pushed to Git.

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