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
