<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 12, 2016 at 8:13 PM, Paul Eggleton <span dir="ltr"><<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Show progress during build and extensible SDK installation.<br>
<br>
I've often thought it would be nice if we could print progress information<br>
for individual tasks so that you could get some idea of whether the task<br>
is doing anything and how much longer it might take, and so I've been working<br>
on a set of patches to implement just that in the background for a while now<br>
and this is the result. Unfortunately this isn't necessarily practical to do<br>
for all tasks, but things like do_fetch are running processes that do output<br>
progress information so it's not too hard to tap into that and present it in<br>
the form of a progress bar next to the task, which is what this patchset<br>
does. I was also able to enable progress for do_compile in recipes that use<br>
cmake (since that outputs % complete as it runs) as well as do_rootfs where<br>
it has a number of internal steps that can be counted and weighted.<br>
<br>
I have contemplated and even prototyped going a step further and using the<br>
count of lines in the output to track progress for *all* long-running tasks,<br>
which does work reasonably well - the caveat is you actually need the<br>
expected line count ahead of time for each task, so you have to be able to<br>
get that from somewhere. I haven't worked out a practical means of<br>
delivering that, suggestions would be very much welcome - my prototype stuff<br>
is on poky-contrib paule/progress-wip and relies on someone profiling a<br>
build containing all the tasks beforehand and that information somehow being<br>
made available to everyone else.<br>
<br>
Also included in this patchset is support for showing progress in a couple<br>
of other stages during the build - when checking for the availability of<br>
sstate artifacts, when initialising the tasks (formerly "Preparing RunQueue")<br>
and overall progress of running setscene and normal tasks.<br>
<br>
There are also a few semi-related changes to improve progress reporting and<br>
speed of extensible SDK installation.<br>
<br>
NOTE: this patchset requires the corresponding set of changes just sent<br>
to the bitbake-devel list in order to work.<br></blockquote><div><br></div><div>This is pretty sweet, nice work on this, Paul. A couple random thoughts:</div><div><br></div><div>1. do_fetch progress is *awesome*, especially for the kernel :)</div><div>2. there are do_setscene progress bars, but they seem to just pop up and vanish in the common case, since they run so quickly. we might want to add a minimum time threshold to the UI, so if the task has been running less than 5 seconds, don't even bother showing it</div><div>3. it may be worth adding a spinner for cases where we don't know the expected line count, but want to be able to indicate that something is happening, i.e. just spin the spinner if output is still coming from the task's stdout, so the user doesn't get paranoid and think the compile hung :)</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>