bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #52922] -Otarget does not function properly and errors on FreeBSD,


From: Paul D. Smith
Subject: [bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe
Date: Thu, 18 Jan 2018 08:13:09 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]