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
