Since August, on master, SwiftPM builds using llbuild as a library instead of through an executable, which allows it to access more information on the progress of the build and more importantly to generate its own command-line output. For now, SwiftPM just replicated the build output that the llbuild executable used to generate, but I'd like to move forward and provide a more pleasant and useful progress animation.
Before I go forward with this, I'd like to get some feedback on what kind of presentation people would prefer. The two important questions are:
Should it be percentage or item based? (item = compilation unit)
Should it display a progress bar?
To help discussion, here are two examples that I could quickly capture:
Please disregard the fact that the Ninja example updates per-file and that the SwiftPM example updated per-module, this is something that will be improved on independently.
I think that item based display is slightly more useful, but then again I can see why someone would prefer to have a percentage. Since you seem to have both implemented, why not make it a flag?
Is the jumping insertion point in the progress-bar row something that can be fixed, or just an oversight in the recording?
Out of curiosity, why is the cursor above the line it ends at? At first I thought it was part of the progress bar, but then I realized that it's part of the second line but it always appears on the line above it.
My personal preference is we start with the Ninja-style, which is well tested and works well in practice.
If we wanted to move to a multiline thing, I would rather explore something a la what Buck has, which displays the behavior on multiple cores. However, I think this can also be quite noisy, so I'd prefer start simple and then explore further innovations...
Thanks for working on this, I have long wanted something better than what we have now!
FWIW, at some point (hopefully not too far off) I would like llbuild to start tracking item times, so that it can offer intelligent heuristic/past-behavior based time estimates (as well as maybe things like critical path times). If you were interested in those, I'd propose we try and do them in llbuild so all llbuild clients can leverage them.
Both are not implemented. SwiftPM currently only has code for handling the percentage-based one. I would personally prefer we start with one and put all the effort into making it awesome.
That's a bug I think. Should be fairly easy to fix.
If we go Ninja style, should we also display a progress bar above it?
No, but I'll make sure to check it out before doing any implementation work. We'll have to tweak ProgressBarProtocol to support updating through a fraction (34/202) instead of a percentage.
I prefer to start with the single line style, which can be rendered in a few places that multiline ones can’t (terminals which honor \r but not full ANSI codes)
One thing to bear in mind perhaps is that some CI systems have trouble displaying in-place updates. (I think this is what @ddunbar is referring to as well.)
I suspect the former version might give better results in that case.
The consensus seems to be on a one-line Ninja-like animation without a progress bar. Are people ok if I replace the default progress bar to that so that the parallel tests also use that same animation? I'd like both testing and building animations to be consistent if possible.
I agree with @finestructure here. CI systems need to be considered. The output of the build process shouldn't be destructive in these cases. We need a full output log in CI.
We detect if the output stream is tty and switch the progress bar. Some services (like Travis) have issues with that so we can just provide an option to control the progress bar type.
Really love the suggestion to have ability to switch between multiple output styles, like Ninja style, Buck style, simple output for CI and so on. I find Buck's per build thread output very helpful.
