On Sun, Jul 25, 2021 at 10:03 AM Paul Smith <psm...@gnu.org> wrote: > Writing to > things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple > concurrent writers to your printers or your terminal!
The user intentionally redirects make to a printer along with another tool. Should make be smarter than the user and refuse? When -O is not specified make will happily run redirected to a printer. > To me the most compelling reason to change the current locking behavior > is not this: I agree with David that simply special-casing /dev/null > could be a good solution; if you're redirecting to /dev/null why even > HAVE a lock? Mike wanted to specify -O and redirect to /dev/null. Again, why should the tool be smarter the user? > The most compelling reason to change the current behavior is that > unfortunately BSD-based systems don't support locking file descriptors > that aren't real files: so if you pipe make's output to something on a > BSD-based system like MacOS or FreeBSD, for example, you get a ton of > error messages. One mechanism to avoid these error messages would be to stat stdout and check S_IFREG. > submake: ; $(MAKE) -C $@ >sub.out > > The way the implementation is today, the outer make and the submake > magically have different "output lock domains", This is an interesting situation. i considered this behavior to be a violation of the contract. The make manual says that when -O is specified the output of the parent and children is synchronized. make is a portable tool and this magic does not happen on windows. i think, we should either fix the deadlock or document that make locks stdout. Otherwise, you see, the users are confused. regards, Dmitry
