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.
