build progress bar

Clemens Lang cal at macports.org
Wed Mar 8 21:29:29 UTC 2017


Hi,

On Wed, Feb 22, 2017 at 03:47:32PM +0100, René J.V. Bertin wrote:
> > 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.

That function, however, also gets called from a myriad of places
throughout other MacPorts code that is not related to build system
output at all. Better change the Pextlib behavior to call a different
function for output generated by the build system instead and implement
your progress handling there, before passing the payload on to ui_info
for logging purposes.

> 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.

I doubt there are many of those. The biggest things we do in Tcl are
some fs-traverse calls. Any non-Portfile code (i.e. in MacPorts base)
can usually better draw a progress bar using other metrics (e.g.
activation could trivially have a progress bar by counting the files it
activates).

> > 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.

You could explicitly re-set a counter at the beginning of a phase and
then use that in between. But then again, that might also be happening
from different files, I guess.

> 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).

Yes, I agree.


-- 
Clemens


More information about the macports-dev mailing list