-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show subcommand output as it happens when only running one command #545
Comments
I thought we had a bug on this, hrmm... someone in the past had tried hacking something like this in -- when we're only running a single command (and we know, due to being in control of the graph, that we won't start another until that one is done), we ought to show that command's output "live". |
I tried to attack this problem at subprocess launch time by not creating pipes, but I’m a fool when it comes to subprocess control and what I did just caused ninja to hang (presumably waiting for some fd to close). But I think my approach was sub-optimal anyway. I think what we want is to always create the pipes, but when we reach a state where everything is waiting for one command to complete, start streaming what’s in its pipe to stdout. @martine, if you’ll drop me a few hints about where/how to approach this, I can take another shot at it. |
I'm not sure, but where I'd start is: Here's a paste of the existing code with a new addition:
It's kinda ugly to special-case the single process there, though, maybe there's some way to refactor this code to have just one flow. And also this function shouldn't be directly printing, it should take a pointer to the caller's This also breaks an assumption made on Windows, where we parse a command's output before displaying it. But I think we can worry about that later and maybe just disable this feature when we're in that state. |
I was thinking about fixing this as well, haven't got time to give it
On Fri, Jun 14, 2013 at 8:17 PM, Evan Martin notifications@github.comwrote:
Maxim |
Hmm, I think I'm a bit out of my depth here, so I think I'd better not sink any more time into this one. Sad to say I'm using make instead of Ninja solely because I can watch the progress of long-running sub-jobs. |
It should also be noted that some applications (e.g. Meson) will print ANSI color coded log messages when they are writing directly to a terminal but plain text when their output is forwarded to a pipe or a file. There are really two cases where you would want to watch the output in real time: regenerating the Ninja file and running the test suite. Neither of these is run concurrently with any other build step. Maybe a new rule variable, let's say unbuffered_output, could be created. When set to true, Ninja would not grab this step's output but rather would let the child process write directly to stdout/stderr. |
I am recalling there was a pull request once doing exactly what you are proposing above, which I couldn't find right now. Also, there is a pull request which I've published recently, #629, where I tried to implement this as I though would be right. May be you could try both and leave a feedback. ;) In addition to the use-cases you are specifying there is another (weak) one, printing long command output in real time (especially when this tool is an "alien" build system building a 3d party library) gives you a chance seeing its output and catching unexpected warning printed by the "tool". |
Another use case for this: I have For this use case, it would be ideal if ninja would allow the task to inherit ninja’s stdin/out/err file descriptors, but such solution does conflict with #629, and it doesn’t really allow ninja to detect, that the task is generating output (for that, we would have to let it write to a pipe instead, but then we lose the tty). |
@sorbits (re #646 (comment)): the reservation is that the current implementation doesn't print ninja status once command running solo starts spewing its output before it finishes. |
But since the configure task runs solo, ninja is not making any further On 7 Sep 2013, at 10:19, Maxim Kalaev wrote:
|
Well, let's just put it that way: as the author of the patch I am happy this works for you. |
Is there any progress on this issue? I'm just as annoyed by this as Dave. Not seeing the output of the unit tests while they're running really sucks. Especially if one of the unit tests hangs. I work around this issue by going to the build directory and run |
Uh, good to know. Sorry for the noise then. :) |
I have two more use cases for cmake re-running itself:
Both of these use cases are non-parallel, and buffering the output is not helpful. |
As above, if you don't want buffering you should make those tasks use the |
Sorry to gravedig 7 years later, but this is the top Google result. Starting in CMake 3.2, you can use |
Your gravedig was very welcome - turned my stackoverflow question into an answer. |
Output buffering is awesome… …but only when there's actual parallelism. For example, a cmake build often contains a bottleneck process that runs all the tests (sometimes in many threads, but ctest manages its own output). If output wasn't buffered, we'd be able to watch a nice progress graph. As things stand, we only get the graph when the build is finished.
The text was updated successfully, but these errors were encountered: