Follow-up Comment #1, bug #52922 (project make): Yes, I'm aware of this as I've seen it happen on MacOS systems myself. Thanks for filing the bug, as I never got around to it.
I've been considering different ways to address the issue including using a lock file on systems where locking of pipes fails. Using a file that all makes have open is itself not an issue, because the parent make can simply open the file and leave it open when invoking submakes. We just need to create a way for the parent to notify the submakes which FD to use for locking. We already do similar things for, for example, the jobserver pipes so this is not breaking new ground. However, using stdout has the nice feature of automatically working correctly if you redirect output (for example, if you invoke a submake and redirect it's output to a file--that submake doesn't need to participate in the same output locking that the parent does and since the stdout is a different file descriptor that just magically happens). So far I haven't found the time to sit down and really think about how this could work correctly using a lock file instead of stdout, or what extra effort make needs to go to. Maybe this enhancement (using a separate lock file for submakes that are redirected) is something that simply won't be supported on those systems as the effort is not worth the reward. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?52922> _______________________________________________ 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