Show progress during build and eSDK install
cover Show progress during build and eSDK install
Show progress during build and extensible SDK installation.
I've often thought it would be nice if we could print progress information for individual tasks so that you could get some idea of whether the task is doing anything and how much longer it might take, and so I've been working on a set of patches to implement just that in the background for a while now and this is the result. Unfortunately this isn't necessarily practical to do for all tasks, but things like do_fetch are running processes that do output progress information so it's not too hard to tap into that and present it in the form of a progress bar next to the task, which is what this patchset does. I was also able to enable progress for do_compile in recipes that use cmake (since that outputs % complete as it runs) as well as do_rootfs where it has a number of internal steps that can be counted and weighted.
I have contemplated and even prototyped going a step further and using the count of lines in the output to track progress for *all* long-running tasks, which does work reasonably well - the caveat is you actually need the expected line count ahead of time for each task, so you have to be able to get that from somewhere. I haven't worked out a practical means of delivering that, suggestions would be very much welcome - my prototype stuff is on poky-contrib paule/progress-wip and relies on someone profiling a build containing all the tasks beforehand and that information somehow being made available to everyone else.
Also included in this patchset is support for showing progress in a couple of other stages during the build - when checking for the availability of sstate artifacts, when initialising the tasks (formerly "Preparing RunQueue") and overall progress of running setscene and normal tasks.
There are also a few semi-related changes to improve progress reporting and speed of extensible SDK installation.
NOTE: this patchset requires the corresponding set of changes just sent to the bitbake-devel list in order to work.
The following changes since commit 2fdd2c1434e7c741b8048145bd460c68bea7ee53:
systemtap: add build dependency on ncurses (2016-06-12 23:47:00 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/startup-oe
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/startup-oe
Paul Eggleton (9):
bitbake.conf: whitelist progress varflag
classes/cmake: enable progress for do_compile
classes/image: implement progress support for do_rootfs classes/sstate: show progress during sstate object availability check classes/sstate: add a mode to error if sstate package unavailable classes/populate_sdk_ext: eliminate double execution on install lib/oe/sstatesig: print locked sigs file message only when explicitly called classes/populate_sdk_ext: show progress when preparing build system toolchain-shar-extract.sh: allow TERM through into SDK installer env
meta/classes/cmake.bbclass | 1 + meta/classes/image.bbclass | 10 +- meta/classes/populate_sdk_ext.bbclass | 7 +- meta/classes/sstate.bbclass | 29 +++++- meta/conf/bitbake.conf | 6 +- meta/files/ext-sdk-prepare.py | 117 ++++++++-------------- meta/files/toolchain-shar-extract.sh | 1 + meta/lib/oe/rootfs.py | 101 ++++++++++++++++--- meta/lib/oe/sstatesig.py | 10 +- meta/recipes-devtools/cmake/cmake-native_3.5.2.bb | 2 + scripts/oe-buildenv-internal | 2 +- 11 files changed, 184 insertions(+), 102 deletions(-)
Signature · 1 line
2.5.5
PATCH 1/9 bitbake.conf: whitelist progress varflag
We don't want the value of this varflag in any signatures since it's only there for the purpose of aiding display of task execution.
--- meta/conf/bitbake.conf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
meta/conf/bitbake.conf +2 -1
@@ -822,7 +822,8 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \ lockfiles type vardepsexclude vardeps vardepvalue vardepvalueexclude \ file-checksums python func task export unexport noexec nostamp dirs cleandirs \ sstate-lockfile-shared prefuncs postfuncs export_func deptask rdeptask \ - recrdeptask nodeprrecs stamp-extra-info sstate-outputdirs filename lineno" + recrdeptask nodeprrecs stamp-extra-info sstate-outputdirs filename lineno \ + progress" MLPREFIX ??= "" MULTILIB_VARIANTS ??= ""
Signature · 1 line
2.5.5
PATCH 2/9 classes/cmake: enable progress for do_compile
In reply to Paul Eggletoncmake outputs percentage complete as part of its compilation process, so we can enable BitBake's new progress scanning for do_compile here.
--- meta/classes/cmake.bbclass | 1 + meta/recipes-devtools/cmake/cmake-native_3.5.2.bb | 2 ++ 2 files changed, 3 insertions(+)
meta/classes/cmake.bbclass +1 -0
@@ -124,6 +124,7 @@ cmake_do_configure() { -Wno-dev } +do_compile[progress] = "percent" cmake_do_compile() { cd ${B} base_do_compile VERBOSE=1
meta/recipes-devtools/cmake/cmake-native_3.5.2.bb +2 -0
@@ -14,3 +14,5 @@ CMAKE_EXTRACONF = "\ -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \ -DHAVE_SYS_ACL_H=0 \ " + +do_compile[progress] = "percent"
Signature · 1 line
2.5.5
PATCH 3/9 classes/image: implement progress support for do_rootfs
In reply to Paul EggletonUse the new task progress functionality to report progress during do_rootfs. I did some timings of the various parts of the do_rootfs code and set some weightings accordingly. This is a little coarse and ideally we would have some progress within the installation section, but it's better than nothing.
--- meta/classes/image.bbclass | 10 ++++- meta/lib/oe/rootfs.py | 101 +++++++++++++++++++++++++++++++++++++++------ 2 files changed, 96 insertions(+), 15 deletions(-)
meta/classes/image.bbclass +8 -2
@@ -198,6 +198,10 @@ fakeroot python do_rootfs () { from oe.rootfs import create_rootfs from oe.manifest import create_manifest + stage_weights = [0.01, 0.1, 0.18, 0.1, 0.03, 0.5, 0, 0.01, 0.02, 0.02, 0.02, 0.01, 0] + progress_reporter = bb.progress.MultiStageProgressReporter(d, stage_weights) + progress_reporter.next_stage() + # Handle package exclusions excl_pkgs = d.getVar("PACKAGE_EXCLUDE", True).split() inst_pkgs = d.getVar("PACKAGE_INSTALL", True).split()
@@ -230,8 +234,10 @@ fakeroot python do_rootfs () { # Generate the initial manifest create_manifest(d) - # Generate rootfs - create_rootfs(d) + progress_reporter.next_stage() + + # generate rootfs + create_rootfs(d, progress_reporter=progress_reporter) } do_rootfs[dirs] = "${TOPDIR}" do_rootfs[cleandirs] += "${S}"
meta/lib/oe/rootfs.py +88 -13
248 lines not on this page · raw message
Signature · 1 line
2.5.5
PATCH 4/9 classes/sstate: show progress during sstate object availability check
In reply to Paul EggletonShow progress through bitbake's standard terminal UI when checking for shared state object availability, since this can take some time if there are a large number of tasks to be executed and/or the network connection is slow.
Part of the implementation for [YOCTO #5853].
--- meta/classes/sstate.bbclass | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
meta/classes/sstate.bbclass +4 -2
@@ -800,7 +800,8 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): except: missed.append(task) bb.debug(2, "SState: Unsuccessful fetch test for %s" % srcuri) - pass + pass + bb.event.fire(bb.event.ProcessProgress("Checking sstate mirror object availability", len(tasklist) - thread_worker.tasks.qsize()), d) tasklist = [] for task in range(len(sq_fn)):
@@ -811,7 +812,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): tasklist.append((task, sstatefile)) if tasklist: - bb.note("Checking sstate mirror object availability (for %s objects)" % len(tasklist)) + bb.event.fire(bb.event.ProcessStarted("Checking sstate mirror object availability", len(tasklist)), d) import multiprocessing nproc = min(multiprocessing.cpu_count(), len(tasklist))
@@ -821,6 +822,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): pool.add_task(checkstatus, t) pool.start() pool.wait_completion() + bb.event.fire(bb.event.ProcessFinished("Checking sstate mirror object availability"), d) inheritlist = d.getVar("INHERIT", True) if "toaster" in inheritlist:
Signature · 1 line
2.5.5
PATCH 5/9 classes/sstate: add a mode to error if sstate package unavailable
In reply to Paul EggletonIf BB_SETSCENE_ENFORCE is set to "1" and an sstate package fails to download outside of the whitelist specified by BB_SETSCENE_ENFORCE_WHITELIST, then fail immediately so you can tell that the problem was caused by failing to restore the task from sstate.
Part of the implementation of [YOCTO #9367].
--- meta/classes/sstate.bbclass | 23 +++++++++++++++++++++++ meta/conf/bitbake.conf | 3 ++- scripts/oe-buildenv-internal | 2 +- 3 files changed, 26 insertions(+), 2 deletions(-)
meta/classes/sstate.bbclass +23 -0
@@ -719,6 +719,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): ret = [] missed = [] + missing = [] extension = ".tgz" if siginfo: extension = extension + ".siginfo"
@@ -740,6 +741,18 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): return spec, extrapath, tname + def sstate_pkg_to_pn(pkg, d): + """ + Translate an sstate filename to a PN value by way of SSTATE_PKGSPEC. This is slightly hacky but + we don't have access to everything in this context. + """ + pkgspec = d.getVar('SSTATE_PKGSPEC', False) + try: + idx = pkgspec.split(':').index('${PN}') + except ValueError: + bb.fatal('Unable to find ${PN} in SSTATE_PKGSPEC') + return pkg.split(':')[idx] + for task in range(len(sq_fn)):
@@ -774,6 +787,8 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): if localdata.getVar('BB_NO_NETWORK', True) == "1" and localdata.getVar('SSTATE_MIRROR_ALLOW_NETWORK', True) == "1": localdata.delVar('BB_NO_NETWORK') + whitelist = bb.runqueue.get_setscene_enforce_whitelist(d) + from bb.fetch2 import FetchConnectionCache def checkstatus_init(thread_worker): thread_worker.connection_cache = FetchConnectionCache()
@@ -800,6 +815,12 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): except: missed.append(task) bb.debug(2, "SState: Unsuccessful fetch test for %s" % srcuri) + if whitelist: + pn = sstate_pkg_to_pn(sstatefile, d) + taskname = sq_task[task] + if not bb.runqueue.check_setscene_enforce_whitelist(pn, taskname, whitelist): + missing.append(task) + bb.error('Sstate artifact unavailable for %s.%s' % (pn, taskname)) pass bb.event.fire(bb.event.ProcessProgress("Checking sstate mirror object availability", len(tasklist) - thread_worker.tasks.qsize()), d)
@@ -823,6 +844,8 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=False): pool.start() pool.wait_completion() bb.event.fire(bb.event.ProcessFinished("Checking sstate mirror object availability"), d) + if whitelist and missing: + bb.fatal('Required artifacts were unavailable - exiting') inheritlist = d.getVar("INHERIT", True) if "toaster" in inheritlist:
meta/conf/bitbake.conf +2 -1
@@ -817,7 +817,8 @@ BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SSH_AGENT_PID \ SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \ PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \ GIT_PROXY_COMMAND ALL_PROXY all_proxy NO_PROXY no_proxy FTP_PROXY ftp_proxy \ - HTTP_PROXY http_proxy HTTPS_PROXY https_proxy SOCKS5_USER SOCKS5_PASSWD" + HTTP_PROXY http_proxy HTTPS_PROXY https_proxy SOCKS5_USER SOCKS5_PASSWD \ + BB_SETSCENE_ENFORCE" BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \ lockfiles type vardepsexclude vardeps vardepvalue vardepvalueexclude \ file-checksums python func task export unexport noexec nostamp dirs cleandirs \
scripts/oe-buildenv-internal +1 -1
@@ -118,7 +118,7 @@ BB_ENV_EXTRAWHITE_OE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \ HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \ -SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA" +SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA BB_SETSCENE_ENFORCE" BB_ENV_EXTRAWHITE="$(echo $BB_ENV_EXTRAWHITE $BB_ENV_EXTRAWHITE_OE | tr ' ' '\n' | LC_ALL=C sort --unique | tr '\n' ' ')"
Signature · 1 line
2.5.5
PATCH 6/9 classes/populate_sdk_ext: eliminate double execution on install
In reply to Paul EggletonUse the new BB_SETSCENE_ENFORCE functionality to avoid having to run bitbake twice on installing the extensible SDK - we can now do it all in one invocation and we should get more meaningful errors.
Part of the implementation of [YOCTO #9367].
--- meta/classes/populate_sdk_ext.bbclass | 5 +++- meta/files/ext-sdk-prepare.py | 52 +---------------------------------- 2 files changed, 5 insertions(+), 52 deletions(-)
meta/classes/populate_sdk_ext.bbclass +4 -1
@@ -223,10 +223,13 @@ python copy_buildsystem () { # warning. f.write('SIGGEN_LOCKEDSIGS_SSTATE_EXISTS_CHECK = "none"\n\n') - # Error if the sigs in the locked-signature file don't match + # Warn if the sigs in the locked-signature file don't match # the sig computed from the metadata. f.write('SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn"\n\n') + # Set up whitelist for run on install + f.write('BB_SETSCENE_ENFORCE_WHITELIST = "%:* *:do_shared_workdir *:do_rm_work"\n\n') + # Hide the config information from bitbake output (since it's fixed within the SDK) f.write('BUILDCFG_HEADER = ""\n')
meta/files/ext-sdk-prepare.py +1 -51
67 lines not on this page · raw message
Signature · 1 line
2.5.5
PATCH 7/9 lib/oe/sstatesig: print locked sigs file message only when explicitly called
In reply to Paul EggletonIf we're building the extensible SDK we don't need to see the "Writing locked sigs" message; it's only necessary when the user explicitly runs bitbake -S none <target>.
--- meta/lib/oe/sstatesig.py | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
meta/lib/oe/sstatesig.py +4 -6
@@ -130,7 +130,9 @@ class SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash): super(bb.siggen.SignatureGeneratorBasicHash, self).set_taskdata(coredata) def dump_sigs(self, dataCache, options): - self.dump_lockedsigs() + sigfile = os.getcwd() + "/locked-sigs.inc" + bb.plain("Writing locked sigs to %s" % sigfile) + self.dump_lockedsigs(sigfile) return super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigs(dataCache, options) def get_taskhash(self, fn, task, deps, dataCache):
@@ -181,11 +183,7 @@ class SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash): return super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, task, stampbase, runtime) - def dump_lockedsigs(self, sigfile=None, taskfilter=None): - if not sigfile: - sigfile = os.getcwd() + "/locked-sigs.inc" - - bb.plain("Writing locked sigs to %s" % sigfile) + def dump_lockedsigs(self, sigfile, taskfilter=None): types = {} for k in self.runtaskdeps: if taskfilter:
Signature · 1 line
2.5.5
PATCH 8/9 classes/populate_sdk_ext: show progress when preparing build system
In reply to Paul EggletonDuring the extensible SDK installation process the final step is to prepare the internal copy of the build system. This can take some time, especially if you have SDK_EXT_TYPE set to "minimal" (downloading sstate artifacts) and SDK_INCLUDE_PKGDATA set to "1" (restoring pkgdata for world). To make this a bit less painful, use BitBake's new quiet mode to display status during this operation so you have some idea of how it's progressing; instead of redirecting the output to preparing_build_system.log we grab the last console log and append it instead.
Part of the implementation for [YOCTO #9613].
--- meta/classes/populate_sdk_ext.bbclass | 2 +- meta/files/ext-sdk-prepare.py | 67 ++++++++++++++++++++++------------- 2 files changed, 44 insertions(+), 25 deletions(-)
meta/classes/populate_sdk_ext.bbclass +1 -1
@@ -427,7 +427,7 @@ sdk_ext_postinst() { # current working directory when first ran, nor will it set $1 when # sourcing a script. That is why this has to look so ugly. LOGFILE="$target_sdk_dir/preparing_build_system.log" - sh -c ". buildtools/environment-setup* > $LOGFILE && cd $target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . $target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python $target_sdk_dir/ext-sdk-prepare.py '${SDK_INSTALL_TARGETS}' >> $LOGFILE 2>&1" || { echo "ERROR: SDK preparation failed: see $LOGFILE"; cat "$LOGFILE"; echo "printf 'ERROR: this SDK was not fully installed and needs reinstalling\n'" >> $env_setup_script ; exit 1 ; } + sh -c ". buildtools/environment-setup* > $LOGFILE && cd $target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . $target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" || { cat "$LOGFILE"; echo "printf 'ERROR: this SDK was not fully installed and needs reinstalling\n'" >> $env_setup_script ; exit 1 ; } rm $target_sdk_dir/ext-sdk-prepare.py fi echo done
meta/files/ext-sdk-prepare.py +43 -24
86 lines not on this page · raw message
Signature · 1 line
2.5.5
PATCH 9/9 toolchain-shar-extract.sh: allow TERM through into SDK installer env
In reply to Paul EggletonIn order to show the task progress during the extensible SDK installation, knotty needs to know it is using a terminal it can support the "interactive" mode on (i.e. ncurses can be used), which means it needs access to the TERM variable value, so allow that through into the cleaned environment within the SDK installation script.
Part of the implementation for [YOCTO #9613].
--- meta/files/toolchain-shar-extract.sh | 1 + 1 file changed, 1 insertion(+)
meta/files/toolchain-shar-extract.sh +1 -0
@@ -2,6 +2,7 @@ [ -z "$ENVCLEANED" ] && exec /usr/bin/env -i ENVCLEANED=1 HOME="$HOME" \ LC_ALL=en_US.UTF-8 \ + TERM=$TERM \ http_proxy="$http_proxy" https_proxy="$https_proxy" ftp_proxy="$ftp_proxy" \ no_proxy="$no_proxy" all_proxy="$all_proxy" GIT_PROXY_COMMAND="$GIT_PROXY_COMMAND" "$0" "$@" [ -f /etc/environment ] && . /etc/environment
Signature · 1 line
2.5.5
Quoted 10 lines · Paul Eggleton
I have contemplated and even prototyped going a step further and using the count of lines in the output to track progress for *all* long-running tasks, which does work reasonably well - the caveat is you actually need the expected line count ahead of time for each task, so you have to be able to get that from somewhere. I haven't worked out a practical means of delivering that, suggestions would be very much welcome - my prototype stuff is on poky-contrib paule/progress-wip and relies on someone profiling a build containing all the tasks beforehand and that information somehow being made available to everyone else.
Could this be done somewhat analagous to the way the sstate stuff works, in the sense you could specify a local or remote line count mirror, or use a local directory. The first time a unique task is run, the line count from the output is saved in the line count db. On subsequent runs, it would detect there's already an entry in the db and would be able to provide the progress report.
Similar to the way an autobuilder can create a shared sstate mirror, when a task is run on an autobuilder, it could save the line count and make it available to other consumers, so on first run you would get a progress report, rather than having to bootstrap the line counts first.
-Bill
Quoted 26 lines · William C
Quoted 2 lines · Paul Eggleton
I have contemplated and even prototyped going a step further and using
the
Quoted 1 line
count of lines in the output to track progress for *all* long-running
tasks,
Quoted 2 lines
which does work reasonably well - the caveat is you actually need the expected line count ahead of time for each task, so you have to be able
to
Quoted 2 lines
get that from somewhere. I haven't worked out a practical means of delivering that, suggestions would be very much welcome - my prototype
stuff
Quoted 2 lines
is on poky-contrib paule/progress-wip and relies on someone profiling a build containing all the tasks beforehand and that information somehow
being
Quoted 1 line
made available to everyone else.
Could this be done somewhat analagous to the way the sstate stuff works, in the
sense you could specify a local or remote line count mirror, or use a local directory. The first time a unique task is run, the line count from the output
is saved in the line count db. On subsequent runs, it would detect there's already an entry in the db and would be able to provide the progress report.
Quoted 7 lines
Similar to the way an autobuilder can create a shared sstate mirror, when a task
is run on an autobuilder, it could save the line count and make it available to
other consumers, so on first run you would get a progress report, rather than
having to bootstrap the line counts first.
I think if you want to do this, then we should do it in a generic way, to store info of that sort from a build and use it as input to another build, i.e. another sqlite3 db or something, as this isn't the only case where build output could be used as hints for another build.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 38 lines · Paul Eggleton
Show progress during build and extensible SDK installation.
I've often thought it would be nice if we could print progress information for individual tasks so that you could get some idea of whether the task is doing anything and how much longer it might take, and so I've been working
on a set of patches to implement just that in the background for a while now
and this is the result. Unfortunately this isn't necessarily practical to do
for all tasks, but things likedo_fetchare running processes that do output
progress information so it's not too hard to tap into that and present it in
the form of a progress bar next to the task, which is what this patchset does. I was also able to enable progress fordo_compilein recipes that use cmake (since that outputs % complete as it runs) as well asdo_rootfswhere it has a number of internal steps that can be counted and weighted.I have contemplated and even prototyped going a step further and using the count of lines in the output to track progress for *all* long-running tasks,
which does work reasonably well - the caveat is you actually need the expected line count ahead of time for each task, so you have to be able to get that from somewhere. I haven't worked out a practical means of delivering that, suggestions would be very much welcome - my prototype stuff
is on poky-contrib paule/progress-wip and relies on someone profiling a build containing all the tasks beforehand and that information somehow being
made available to everyone else.Also included in this patchset is support for showing progress in a couple of other stages during the build - when checking for the availability of sstate artifacts, when initialising the tasks (formerly "Preparing RunQueue")
and overall progress of running setscene and normal tasks.
Quoted 6 lines
There are also a few semi-related changes to improve progress reporting and speed of extensible SDK installation.
NOTE: this patchset requires the corresponding set of changes just sent to the bitbake-devel list in order to work.
This is pretty sweet, nice work on this, Paul. A couple random thoughts:
1. do_fetch progress is *awesome*, especially for the kernel :)
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
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 :)
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics