Update of bug #39035 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Operating System:
Update of bug #39028 (project make):
Item Group:None = Enhancement
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:
Update of bug #38945 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
On Sun, 2013-05-26 at 22:05 +0200, Stefano Lattarini wrote:
On 05/26/2013 09:57 PM, Paul Smith wrote:
[SNIP]
Might be worthwhile checking the FreeBSD code for their make, to see if
they do something like this.
Nope, Frank was right: when run in parallel mode, FreeBSD make
On 05/26/2013 10:20 PM, Paul Smith wrote:
On Sun, 2013-05-26 at 22:05 +0200, Stefano Lattarini wrote:
On 05/26/2013 09:57 PM, Paul Smith wrote:
[SNIP]
Might be worthwhile checking the FreeBSD code for their make, to see if
they do something like this.
Nope, Frank was right: when run in
Update of bug #38442 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
On Mon, 2013-05-20 at 19:06 +0300, Eli Zaretskii wrote:
I still don't want to add back the pointer to the struct. Memory usage
by GNU make is becoming a sore spot, especially as larger and larger
build systems start to move to non-recursive make. If necessary we'll
need to make the list
Paul Smith wrote:
Nevertheless, I do wonder whether forcing stdout/stderr into O_APPEND
mode would be worthwhile. It would fix this problem in any event. I'm
having a hard time coming up with a reason NOT to do it.
One issue, though it might seem strange that I'm the one to mention
it, is
