build progress bar

[Clemens Lang]

On Thu, Mar 09, 2017 at 09:45:44AM +0100, René J.V. Bertin wrote:
> 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.

I'd say such an approach should come with a way to disable it or pass in
a reference/function to invoke for new progress output to avoid this
situation.

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

I must say I'm not particularly good at discussing code in snippets on a
mailing list, so please excuse me for not commenting on this.


On Sat, Mar 11, 2017 at 08:16:27PM +0100, René J.V. Bertin wrote:
> I'm trying to implement the approach below, adding some code to proc
> ui_message in macports.tcl
> 
> {{{
>             # progress reporting
>             if {[may_have_progress_info]} {
>                 if {!${macports::portverbose}} {
>                     ui_progress_display_from_message $string
>                 }
>             } elseif {${_reporting_progress_}} {
>                 #puts "end progress reporting"
>                 if {[info exists $macports::ui_options(progress_generic)]} {
>                     $macports::ui_options(progress_generic) finish
>                 }
>                 set _reporting_progress_ no
>             }
> }}}
> 
> but for the hell of me I cannot toggle the "may report progress" state
> from proc command_exec in portutil.tcl.

Have you considered that code in macports.tcl runs in a different
interpreter than code in the port1.0 folder? macports.tcl creates a
sub-interpreter for running Portfiles.

Take a look at how the progress reporting works for the download
progress bar to get an idea how to pass things through this boundary.


> It's as if the code in portutil.tcl and macports.tcl execute in
> completely different memory spaces;
> `macports_util::command_may_report_progress` will appear to be true
> from within portutil.tcl but will remain false from within
> macports.tcl.

That's the effect of the sub-interpreter and actually desired. Portfiles
shouldn't be able to modify the global macports state in uncontrolled
ways.

-- 
Clemens