On Sun, Jul 25, 2021 at 3:25 PM Paul Smith <psm...@gnu.org> wrote: > I have no problem with make refusing to write to a device that's locked > in general. If users don't want that to happen, they can just not use > the -O option.
True, as long as the user knows that when -O is specified make is going to lock stdout. > It's clear that /dev/null is a special case, however, because the order > in which data is written to it cannot be detected so what's the point > in preserving any order? Maybe Mike can tell us. > What I'm saying is that IF make can detect that its stdout is going to > /dev/null then it shouldn't lock at all, because it's not necessary to > do so in order to meet the goals of the -O option, and doing so > introduces unnecessary latency in the build. Even if we come up with a portable mechanism to detect /dev/null, what about other files? What about /dev/stdout or /dev/pts/5? i don't think, it is possible or even reasonable to attempt to special case all these files. > The question is what to do about supporting -O on these systems. A private temp file will work. > That's true but there are, unfortunately, some edge cases where Windows > and POSIX systems behave differently. True. Is this case really one of those edge cases? > The goal is to provide the best implementation of make for the GNU system What do you think we should do about this bug report? regards, Dmitry
