Status table

[moroten]

This series of commits creates a new status output, inspired by https://buckbuild.com/static/buck-build-15fps.gif at https://buckbuild.com/. I've tried to make the console work well when resizing. It does not fill the whole console window, by purpose, so that the user can see the latest output above the currently running tasks.

Estimating the time left is of the simplest kind without using the .ninja_log.

Use NINJA_STATUS_TABLE as well as NINJA_STATUS to configure the top status line in the table.

It has not been tested for user input during pool=console. I've been running an earlier draft for a while on a quite big project (50 MB ninja file) for a few months now, on Windows. Only basic tests has been performed on Linux, building Ninja itself.

> ninja.exe all
[38/55] LINK ninja.exe
Generating code
Finished generating code
[50/55] 26.7 elapsed,  2.7 left
 5.8s CXX build\test.obj
 4.2s CXX build\manifest_parser_test.obj
 1.0s CXX build\ninja_test.obj
 0.8s CXX build\edit_distance_test.obj
 0.8s CXX build\state_test.obj
 0.1s CXX build\hash_collision_bench.obj

See also https://groups.google.com/d/msg/ninja-build/lK5YVv5Y4T4/fjqQAjoJKrsJ

[sgraham]

Cool, I like the output. :)

Minor build issue on VS2015:
d:\src\ninja\src\build.cc(327): warning C4457: declaration of 'edge' hides function parameter

I'm not sure about console_height/2 for the limit, but it also seems heavy to add another config parameter for that, so maybe it's fine.

[moroten]

I did try console_height/4 (above), but I thought the stdout/stderr above was too small when getting compiler errors.

[moroten]

I replaced the edge variable with cur_edge. Thanks for spotting.

(Is git-rebase the method to use on GitHub? Where can I see the differences between the versions? I'm used to Gerrit where I rebase all the time.)

[nicolasdespres]

I like this output too.

I am wondering how we could make it fit in a larger patch addressing most of the issues referenced by #746.

[nicolasdespres]

It would be nice to have enough tools inside Ninja to be able to implement such output as an external filter command.

[wjakob]

This looks very interesting. How would this visualization behave when compiling on a machine with many cores that are becoming increasingly common? The latest Xeon Phi machines boot up with 256 virtualized cores, which means that it won't generally be possible to even fit that many lines on a screen.

[moroten]

In src/line_printer.cc:88, LinePrinter::PrintTemporaryElide(), the code states lines_above_us = max(1, console_height / 2). The status table will never fill more than half of your console, it adds ... at the end if any lines were cropped.

[Sarcasm]

Just a few comments, as I have been using these patches for about 10 months now, and like to share my interest in it.
I find it very useful!

Most notably, I can see which files are taking most of the time to build, and how long that is.
That makes me want to fix the issues with this files, as compilation time in C++ can be quite painful.

I've got some issue with it:

• I have yet to see a correct estimate for the time left
• at the end of compilation, there if very often some empty lines after the prompt, which is unusual compared to any other shell commands, event ncurses-based applications, and annoying because when there are compilation errors you often need to scroll the output

[mathstuf]

at the end of compilation, there if very often some empty lines after the prompt, which is unusual compared to any other shell commands, event ncurses-based applications, and annoying because when there are compilation errors you often need to scroll the output

I suspect this PR is not using the alternate window effectively (though I've not looked or tested the code). A screenshot would help.

[Sarcasm]

Before starting ninja, cursor it at the bottom of the window:

After ninja ran, the cursor is not at the bottom, there is a few rows left at the bottom of the window:

[mathstuf]

Using the alternate window should fix that, but you might also lose the [6/6] Finished line as well if it weren't echoed again upon switching back to the primary window. Compiler warnings/errors may also need special handling.

[Sarcasm]

What's this "alternate window" thing?

[mathstuf]

This SO question seems to explain things: https://stackoverflow.com/questions/11023929/using-the-alternate-screen-in-a-bash-script

[Sarcasm]

Ok thanks, indeed, that could be it.

[Sarcasm]

Tried it, but we lose the ninja output on termination, which is not nice.
Also, when ninja runs, what was there before is cleared, which is also unusual.

I feel like maybe it will be the best to not clear out on exit, but just to leave the last few lines.
It could be nice as so that we have the elapsed time still visible eventually, and maybe the time of the last command.

To get an idea, I killed ninja with SIGSEGV so that it does not do the cleanup.
This leave the cursor to the desired position.

[moroten]

Thank you all for the feedback. Sorry for the late reply.

I saw a PR which always printed the longest running edge instead of just the latest started or latest finished. That behaviour is probably enough for my use case. Then I can see what commands are slow, even though the exact elapsed time is not there. (Looked around but could not find that PR again.)

Anyway, I'm switching to Bazel since so I will not maintain this PR any more. Please feel free to take it over (copy it?) or just close it.