build progress bar

[Clemens Lang]

On Mon, Feb 20, 2017 at 10:17:05PM +0100, René J.V. Bertin wrote:
> I don't think I was the one who wrote that :)

Hence the double quotation markers as opposed to single ones where I was
quoting you.

> Speaking of "quite a few people" who provide line number info: how do
> you consider handling if their information doesn't match, for instance
> because not everyone is using exactly the same compiler and compiler
> options?

Average and/or median would probably be close enough in most cases. We
could also add compiler versions to the mix.

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

> Evidently, but it's not the opt-in sending of information that I find
> a bit frown-worthy. You either decide to participate or you don't.
> It's the fact that you'd need to query a remote server each time you
> start a build if you want to have progress information.

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

> Independent of that there's also the fact that ultimately the progress
> reporting mechanism will hook into the existing code at a level where
> it gets executed for every line that's being logged, so there's a bit
> of a performance concern.

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.

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

-- 
Clemens