[bug #65268] Reset O_APPEND mode for stdout and stderr

[Paul D. Smith]

Update of bug #65268 (group make):

  Item Group:None => Bug
  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Component Version:None => 4.0
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Fixed, thanks for the report.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65359] submake might will lose variable values if their names contain special char

[Paul D. Smith]

Update of bug #65359 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #8:

Added some notes about this, thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64085] -e passed to shell in POSIX mode with -i or .IGNORE

[Paul D. Smith]

Update of bug #64085 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

Fixed, thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65448] $(intcmp) problems with negative integers

[Paul D. Smith]

Update of bug #65448 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

Fix applied; thanks Jouke


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: suggestion regarding names of temp files

[Paul Smith]

On Mon, 2024-03-18 at 13:04 -0400, DSB wrote:
> Minor suggestion: In 9.7 Temporary Files the manual says "These files
> must not be disturbed while make is running" but it doesn't say what
> "these files" look like. Assuming the names have some pattern, would
> it make sense to be more specific and say something like "do not
> remove temp files matching gnumake.*"?

I added some info about this to the GNU Make manual, thanks for the
note!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: confusing language in manual re GNUMAKEFLAGS

[Paul Smith]

On Tue, 2024-03-05 at 08:54 -0500, DSB wrote:
> I think this little nit should be cleared up. In one place the manual
> says:
> 
> ... after parsing GNUMAKEFLAGS GNU make sets this variable to the
> empty string ...
> 
> But in another place it says:
> 
> GNU make never sets this variable itself.
> 
> The meaning is clear (to me) but the language is not well formed.

I tried to clarify this; thanks for the note!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: Issue with 'src/variable.c'

[Paul Smith]

On Wed, 2024-02-07 at 13:35 +0100, Gisle Vanem wrote:
> Since the commit:  
> https://git.savannah.gnu.org/cgit/make.git/commit/src/variable.c?id=ec348f51d0240ebc64d11c77c461e89c4a8dfed7
> 
> src/variable.c doesn't compile:
>    variable.c(1642): error C2065: 'specificity': undeclared
> identifier
>    variable.c(1658): error C2065: 'specificity': undeclared
> identifier
> 
> Should it be:

The proposed patch is actually backwards (it should be NULL if the
scope is global, not the current_variable_set_list).

However I applied a fix, thanks for the note!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: [PATCH] Fix integer overflow test in parse_int

[Paul Smith]

On Sun, 2024-01-07 at 16:09 -0800, Paul Eggert wrote:
> * src/arscan.c (parse_int): Use intprops.h macros rather than trying
> to detect integer overflow by hand, and doing it incorrectly.
> Here is an example of why the old code was incorrect.
> If val == 3689348814741910323, base == 10, *ptr == '0', UINTMAX_WIDTH
> == 64,
> then (val * base) + (*ptr - '0') yields 18446744073709551614,
> which is greater than val even though overflow has occurred.
> Fortunately this bug could not be triggered on GNU/Linux hosts,
> although it may be possible on platforms (if any) where struct ar_hdr
> has members so large that they can represent integers that do not fit
> int uintmax_t.

I applied this, thanks for the patch Paul!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: [PATCH] Fix jobserver does not work on OS/2

[Paul Smith]

On Wed, 2023-12-13 at 20:05 +0900, KO Myung-Hun wrote:
> mkfifo() on OS/2 is a dummy, even it returns a wrong value on error.
> 
> Do not use it on OS/2.

I applied this change, thanks!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

Re: Pattern rules without recipe

[Paul Smith]

On Fri, 2023-06-09 at 09:39 +0200, Frank Heckenbach wrote:
> Another thing that surprised me which I assume is working as
> designed, but I think should be spelled out clearer in the manual:

I added a paragraph about this to the main page describing pattern
rules.  Thanks for the note!

-- 
Paul D. Smith Find some GNU Make tips at:
https://www.gnu.org   http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

[Yuri]

URL:
  

 Summary: gmake-4.4.1 has a performance regression: at least
the nwchem project now builds much slower
   Group: make
   Submitter: yurivict
   Submitted: Fri 29 Mar 2024 06:50:10 AM 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: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Fri 29 Mar 2024 06:50:10 AM UTC By: Yuri 
When the FreeBSD port devel/gmake was updated from 4.3 to 4.4.1 on 2024-03-03,
the nwchem project build slowed down. It used to build in 1-1.5 hours, and now
it builds in 10+ hours.

The nwchem build runs a lot of shell commands.

Some GNU make changes caused this.

Did anyone else reported performance problems?
How can performance regression be fixed?








___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/