On Wednesday February 22 2017 14:57:17 Clemens Lang wrote: Hi,
> in incremental builds). Regardless, incremental builds are uncommon for our > users aside from "power users". True, my point is that those power users are probably more likely to appreciate progress reporting. The average Joe or Jane user probably launches an upgrade or install and goes on to do something else. In fact, I myself would probably be more interested in a progress bar during an incremental build because more likely to sit around and wait for it to finish. I tend to plan expensive builds I know will take too long to wait for, and in that case checking the logfile from time to time is usually good enough. > Well, the magic happens in > > > https://github.com/macports/macports-base/blob/master/src/pextlib1.0/system.c#L303 > > so it seems we do call to Tcl once for each line generated by a build system. Yep, so I wasn't mistaken in my analysis. Actually, the system function hands off the output string to ui_info(), which ultimately leads to a C version of ui_message being called: https://github.com/macports/macports-base/blob/master/src/pextlib1.0/Pextlib.c#L113 > That's probably buffered, though, so those calls happens every few KB of > output. That's the impression I have from doing `tail -f` on log files. > This is also the place where progress reporting could be added. ... > Yes. Probably still not a good idea to put progress guessing into the > implementation of ui_info, though. proc ui_message is where I've put it because that's the function that gets called from Pextlib. Putting it there instead of in C code means you could also do (line-number based) progress reporting for long operations that are written in pure Tcl. > Which file? Why do you need to call start and finish from different files? > That > sounds like a problem waiting to happen if you do the progress setting from > macports.tcl but the start and finish from somewhere else. Yes, but take the case of the build phase. proc ui_message has no way of knowing when that phase starts unless it starts tracking changes in macports::current_phase . And that's probably something we'd want to avoid to prevent unnecessary overhead. The logical places to inform the progress reporter that it needs to rewind (or is done) are in portbuild.tcl or possibly more generically in portutil.tcl (proc command_exec; start just above "Call this command", finish just before returning). R.
