[bug #39035] problem with blanks in continuation line in a recipe
Update of bug #39035 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Operating System: POSIX-Based = Any Fixed Release:None = SCM ___ Follow-up Comment #1: Fixed in Git. Thanks for the report! ___ Reply to this item at: http://savannah.gnu.org/bugs/?39035 ___ 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 #39028] [patch] fix and uniformize four error messages
Update of bug #39028 (project make): Item Group:None = Enhancement Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = SCM ___ Follow-up Comment #1: OK fixed, thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?39028 ___ 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 #38945] [PATCH] Fix CRLF backslash-newline handing on non-WINDOWS32 platforms
Update of bug #38945 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = SCM Triage Status: Need Info = Verified ___ Follow-up Comment #5: Fixed. Thanks for the repro case! ___ Reply to this item at: http://savannah.gnu.org/bugs/?38945 ___ 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: Make run in parallel mode with output redirected to a regular file can randomly drop output lines
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 unconditionally behaves like GNU make does with the '-O' option enabled (I behavior I actively dislike, since it cannot be worked around). And it also has several other terrible hacks and quirks. For more info, see: http://www.gnu.org/software/autoconf/manual/autoconf.html#Parallel-Make 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. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines
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 parallel mode, FreeBSD make unconditionally behaves like GNU make does with the '-O' option enabled (I behavior I actively dislike, since it cannot be worked around). And it also has several other terrible hacks and quirks. For more info, see: http://www.gnu.org/software/autoconf/manual/autoconf.html#Parallel-Make 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. To be clear: I'm not opposing to the change in any way; it's just that I don't feel comfortable enough with the area to give an explicit ACK. If you think the change would be worthwhile, go for it :-) I trust your judgment far more than mine. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38442] Field 'name' not cached
Update of bug #38442 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = SCM Triage Status: Need Info = Verified ___ Follow-up Comment #6: Fixed in Git. Thanks for the report! ___ Reply to this item at: http://savannah.gnu.org/bugs/?38442 ___ 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: GNU make release candidate 3.99.90 available
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 a bit more sophisticated so we can add new elements to it if/when we rename targets. How about if we bite the bullet now, and simply add a fully qualified absolute file name of the dynamic object? I'm not against it, but I'm not sure it's sufficient. What we need is to ensure that whatever name exists in the struct file can be looked up in that list. Make generally has a problem with multiple names for the same target. I had played with the idea of storing inode information to try to determine if two different paths are the same file, but (a) that doesn't work on non-POSIX systems so well, and (b) it doesn't help if some rule recreates a file, giving it a new inode. We have the name and hname values already, and the hname value is intended to be a hashed lookup name which different struct file's referring to the same file will share, but this are not guaranteed to be enough, I think. Unfortunately finding the fully-qualified pathname of a file is VERY expensive, so I don't think we can just do it as a matter of course. To get this working efficiently we'd need to keep some kind of cache of fully-qualified directory paths, than we can try to figure out what directory a given file belongs to. Even this will be problematic dealing with make rules which create/delete directories and/or symlinks, and might invalidate the cache. And handling symlinks that might change directory paths can lead to problems trying to resolve paths like foo/../bar. This entire area needs careful thought. I believe there is at least one Savannah bug related to this already. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines
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 that it might be POSIX specific. How do other systems behave, can they set O_APPEND via fcntl or otherwise, and if so, does it guarantee non-conflicting writes? Of course, you could say an improvement that only works on some systems (as long as doesn't negatively affect other systems) is better than nothing, but it might give package maintainers a false sense of safety in keeping a problematic way of doing things rather than modifying their packages to do it safely right away (like Stefano just did as I understand it). Though, if O_APPEND doesn't guarantee non-conflicting writes *at all* (i.e., even when set on opening, as in make logfile) on some systems, it's not really safe either. Of course, you can construct a theoretical case, such as someone setting up a large empty file, seeking to its beginning and expecting their make jobs to write there. I can't think of any practical reason to do this, but as with most of the -O and related discussions, I'm sure someone will tell us about such a scenario soon. :-) Neither of may be a very strong argument, but my gut feeling is that this is slightly outside of the scope of what make should do. But in any case, I don't have a strong opinion since I'll be using output-sync from now on anyway. Stefano Lattarini wrote: An now that I think about it, maybe the sanest fix would be just documenting the issue in the manual? I tend to agree. Perhaps a sentence or two in Parallel Output, mentioning that output-sync will also avoid this problem. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
