build progress bar

René J.V. Bertin rjvbertin at gmail.com
Thu Mar 9 08:45:44 UTC 2017


On Wednesday March 08 2017 22:29:29 Clemens Lang wrote:
>Hi,
Hi,

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

I don't disagree, but how would we determine from there that a build is going to be done (or destroot, I'd add that step too)? Or would we simply support progress logging for everything invoked through Pextlib's system call (SystemCmd, IIRC)?

That would solve the question of where to initialise and terminate the progress reporter but wouldn't it add an extra layer of complexity to calling the progressbar "class" defined in Tcl in the port client? It wouldn't be very nice if the system command all of a sudden starts failing when used in a context where that progressbar class isn't accessible.

If ui_message contains a few additional lines like below, wouldn't the overhead drown in the noise of what's already going on if there's nothing to report?

{{{
    if {ui_may_have_progress_info} {
        if {![ui_isset ports_verbose]} {
            # check _reporting_progress_, initialise progress reporting if not set
            # call a procedure that checks for and processes progress info
        }
    } elseif {_reporting_progress_} {
        # finalise
        _reporting_progress = no
    }
}}}

I think that should give not more than an acceptable overhead (and a small enough addition to proc ui_message) at least for a first approach, allowing us to get a better idea what kind of progress reporting is feasible and useful. In this kind of situation optimisation through refactoring into compiled code is usually something one does in a 2nd step, when justified, no?


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

I think the variation and code snippet above address the problem. I'd have to try to see if this can really work but I think it should, and it ought to allow to put all the code that does the actual progress reporting stuff in macports.tcl . Files that start or terminate operations that might provide progress info only have to set or `unset ui_may_have_progress_info` and maybe provide the equivalent of a function pointer to a procedure that provides the progress information itself.

R.


More information about the macports-dev mailing list