On Saturday February 18 2017 17:27:45 Ryan Schmidt wrote: > The problem is that it only applies to cmake-generated makefiles and certain > other one-off makefiles. But maybe a progress bar for some builds is better > than no build progress bar ever.
Yeah. It might work for any project that uses ninja, too. > For example, a port building with cmake and muniversal will go from 0% to > 100% for the first architecture, then go from 0% to 100% for the second > architecture; this detail should be hidden from the user behind a single > combined progress bar. Or the muniversal portgroup could indicate what architecture it's building for. I've already hacked my copy to do that because it also provides a periodic wake-up call to ask myself if I really need that port installed +universal. That's a different issue of course. > The ticket for this issue is https://trac.macports.org/ticket/15939 . Clemens > had some thoughts there for how it might be done for other ports whose build > systems don't provide this information, but it would involve maintaining an > online database. Ah yes. In my memory someone suggested using the number of files, but the number of output lines would be a reasonable indicator if you know how many there are. If we go for an approach that relies on ports (or portgroups) providing the required information it should also be possible to provide the number of expected lines that way, removing the need for an additional online database. Something like {{{ build.progress.expected_lines 1000 }}} should be all that's needed to activate a progressbar mechanism based on this generic principle. R.
