Re: [bug #33134] spurious error when stdout is already closed
On Thu, Apr 21, 2011 at 1:48 AM, Philip Guenther guent...@gmail.com wrote: [...] All quite true and admirably researched but this is not a standards-lawyering exercise, it's a software-engineering issue. I can't remember how many installers I've run which, when cancelled, finish by saying ERROR - the software is not installed!. And I always think That's not an error, I got what I asked for. The only error would be if the product ended up installed. Here we have the same thing. If the user has explicitly closed stdout before handing it to make, does s/he need to be alerted to that fact by make? And even if so, should it take the form of an ERROR message? I'd say no, because when the user gets exactly what s/he asked for that cannot be regarded as an error condition. If make feels the need to say Warning: unable to write to stdout because it's closed that would be reasonable, though a little fussy for my taste, but there's no error condition here. I feel like we're trapped in a classic Internet chest-thumping loop, but my day job requires that I break it. I'd say the bug report exists and this thread provides all the commentary one could wish, so I'm sure Paul will be in a position to make an informed decision when he gets to it, and let's leave it at that. David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33134] spurious error when stdout is already closed
Follow-up Comment #1, bug #33134 (project make): Note that there is a thread on the bug-make mailing list discussing this in some detail: http://lists.gnu.org/archive/html/bug-make/2011-04/msg00077.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?33134 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33134] spurious error when stdout is already closed
On Thu, Apr 21, 2011 at 3:50 AM, David Boyce david.s.bo...@gmail.com wrote: All quite true and admirably researched but this is not a standards-lawyering exercise, it's a software-engineering issue. Why are you closing stdout instead of redirecting it to /dev/null? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33134] spurious error when stdout is already closed
On Thu, Apr 21, 2011 at 11:29 AM, Philip Guenther guent...@gmail.com wrote: On Thu, Apr 21, 2011 at 3:50 AM, David Boyce david.s.bo...@gmail.com wrote: All quite true and admirably researched but this is not a standards-lawyering exercise, it's a software-engineering issue. Why are you closing stdout instead of redirecting it to /dev/null? While developing a patch for the .PARALLELSYNC feature being discussed in another thread (#33138), I tested a number of corner cases which included stdout being closed. That helped me find some bugs in my work but I also noticed that even unmodified make had this behavior, so I submitted a standalone patch to fix it. So - in this context at least - I'm not a user doing a dumb thing, I'm a developer doing a careful thing. In real life I've never had a valid reason to close stdout. David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
I've filed this as an enhancement request (https://savannah.gnu.org/bugs/index.php?33138) for better tracking. Unfortunately there's a typo in the headline which I can't fix. David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33134] spurious error when stdout is already closed
Follow-up Comment #2, bug #33134 (project make): My original one-line patch had two mistakes, which may be a record! In the course of work for enhancement #33138 I made a macro: #define STREAM_OK(strm) ((fcntl(fileno((strm)), F_GETFD) != -1) || (errno != EBADF)) whose logic would be much better than the original ftell(). Turns out that on many platforms ftell cannot be used on a non-seekable descriptor at all. My development is on Solaris where ftell works as a go/no-go indicator, but that isn't portable. And the EBADF test is required for reasons which are obvious and also discussed in the email thread. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33134 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33138] .PARLLELSYNC enhancement with patch
URL: http://savannah.gnu.org/bugs/?33138 Summary: .PARLLELSYNC enhancement with patch Project: make Submitted by: boyski Submitted on: Thu 21 Apr 2011 04:17:07 PM GMT Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: CVS Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: A patch will be provided to support a new special target, tentatively called .PARALLELSYNC, which keeps the output of parallel jobs discrete. The background is amply described in a long thread starting at http://lists.gnu.org/archive/html/bug-make/2011-04/msg00018.html My patch will only address POSIX systems but with luck this can be ported to the full set of platforms which also support -j ___ Reply to this item at: http://savannah.gnu.org/bugs/?33138 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
