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