build progress bar

René J.V. Bertin rjvbertin at gmail.com
Tue Feb 21 19:29:45 UTC 2017


On Tuesday February 21 2017 19:52:27 Clemens Lang wrote:

>> And the other thing that was mentioned, incremental builds. Do you
>> also see a clever solution to the challenge those pose?
>
>No, unfortunately not. I don't think line counts work for incremental
>builds at all, but fortunately they wouldn't be a very common use-case.

I'm pretty sure they won't, but I think that incremental builds might be more common than you think among the users who are esp. interested in progress reporting. 

The progress info provided by Ninja and CMake+Make works in those cases.

>This could be solved by updating a database once before all builds.

That would work, but only for batch builds.

>We already run C code for every line of output produced by a port's
>build system. Of course calling back into Tcl for each line isn't
>possible, but keeping track of the last call and invoking a Tcl callback
>every second, for example, is entirely possible.

That's what I thought too initially, but as far as I've found the Pextlib/C version of ui_info and family do exactly that: they call the Tcl versions. That's why my current barebones prototype that just prints "XX% done" works. Am I overlooking something? It does make sense, in the end.

>> Let me ask about my blocker once more: how do I get at
>> macports::ui_options(progress_generic) from macports.tcl?
>
>See the rev-upgrade code, which is in macports.tcl and draws a progress
>bar.

My bad, macports.tcl has access to macports::ui_options. The blocker is that I need to call the start and finish methods from another file, and I haven't managed to access macports::ui_options from there.

R.


More information about the macports-dev mailing list