On Tue, Oct 27, 2015 at 08:57:17 -0400, Paul Smith wrote: > On Mon, 2015-10-26 at 21:36 -0400, Ben Boeckel wrote: > > The way Ninja has solved this is with the "console" pool which > > indicates that the rule should not run with any other rule in parallel > > and that it needs exclusive access to the terminal. > > It's not possible to have an indication that the rule should not run > with any other rule in parallel: the output sync only manages output, > not runtime.
I wasn't thinking this would be something necessarily related to -O options. > It would be possible to add a facility where a job takes the output > stream lock BEFORE the rule runs, and relinquishes it only after the > rule completes (normally the job runs first and only takes the output > stream lock after the job completes, in order to dump the output, then > relinquishes it). This would ensure that only that job was using the > terminal and it wouldn't get interrupted. It would have the effect of > causing all other jobs to pause after they were completed and new jobs > to not be able to start because they can't dump their output, until the > terminal is freed up. This sounds sufficient to me. One corner case I can think of is whether recipes with no output also go through the output lock. > Note that ninja can do this kind of thing much more easily because it > doesn't need to worry about recursive invocations so one ninja process > has a total view of all jobs in the build system and they can easily be > coordinated. Recursive make does sound like a nasty corner case though :( . I also suppose ninja *could* care about recursive ninja, but instead just points to "you shouldn't do that". > > It also seems that MAKE_TERMERR and MAKE_TERMOUT are kind-of lies with > > -O. > > I don't know what this means. Ah, sorry for not being clear. They come out as /dev/pts/$x when they're really writing to a pipe (which is fine for color detection, but if they turned into somethine else, then the rule could error out that -Otarget and friends aren't supported). Thanks, --Ben _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
