bug-make
[Top][All Lists]
Advanced

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

Re: -Otarget + ncurses applications


From: Ben Boeckel
Subject: Re: -Otarget + ncurses applications
Date: Tue, 27 Oct 2015 09:12:49 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

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



reply via email to

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