1466698 - Enable Tup's progress bar when building with the tup backend

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[Chris Manchester (limited bugmail, email directly)]

It's a pretty killer (and oft-requested feature) when it works. Tup detects whether stdout is a tty and enables the progress bar based on that, but mach redirects stdout of the tup build process to a pipe, so that doesn't work. We can pass `pass_thru=True` to `run_process`, but for some reason that makes it so we can no longer kill the build process with ctrl-c.

The simplest way forward for this might be to add a flag to tup to force-enable the progress bar.

Comment 1

[Michael Shal [:mshal]]

We can force tup to use the progress bar by specifying some values in the .tup/options file:

[display]
progress = 1
width = 80

The 'progress' option defaults to 1 if we have a TTY, so overriding that enables the progress bar. The 'width' option defaults to the value from an ioctl(STDOUT_FILENO, TIOCGWINSZ) call, which ends up failing when tup is invoked from mach (this may also require a tty?). Overriding it manually allows tup to display the progress bar, but the result is a mess since the escape sequences to overwrite the progress bar are eaten somewhere. It ends up looking like this:

 0:01.24  [   ]   0%
 0:01.24  [   ]   0%
 0:02.03  [   ]   0%
 0:02.03  1) [0.790s] obj-x86_64-pc-linux-gnu/xpcom/ds: CXX /home/mshal/mozilla-central-git/xpcom/ds/nsGkAtoms.cpp
 0:02.99  [   ]  23%
 0:02.99  2) [1.754s] obj-x86_64-pc-linux-gnu/xpcom/ds: CXX Unified_cpp_xpcom_ds1.cpp
 0:04.03  [.  ]  64%
 0:04.03  3) [2.797s] obj-x86_64-pc-linux-gnu/xpcom/ds: CXX Unified_cpp_xpcom_ds0.cpp
 0:04.03  [...] 100%

So I think we'll need a better way to integrate this with mach, possibly by having tup just pass job information to mach and then allowing mach to do the progress display. Alternatively, we can try to figure out a way to have mach give tup a tty for local builds, but that might impact things like warnings.json that require parsing the build output.

Comment 2

[(not currently active) Ted Mielczarek]

The "mach eating escape sequences" bit reminds me of bug 1417003. Maybe that's not workable.

Comment 3

[Chris Manchester (limited bugmail, email directly)]

It looks like there a few places in mach, mozprocess, and even the python standard library logging module that might be eating our carriage returns. Maybe we should just circumvent mach/mozprocess when invoking the tup process for now. mshal is right that the warnings db and other niceties might require re-implementing the progress display in mach.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Given the blocked bug is wontfix this probably is too...