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