On Tue, 2013-09-10 at 08:30 -0700, Darren Hart wrote: > On Fri, 2013-09-06 at 18:12 +0200, Peter Kjellerstedt wrote: > > This makes sure the the first build starts from a clean state. Otherwise > > one could have the first build affected by any leftover state from > > a previous build. > > > > This also leaves a working state behind after the final build. > > > > Signed-off-by: Peter Kjellerstedt <[email protected]> > > Hi Peter, > > Thanks for taking the time to send in a fix! > > > --- > > scripts/contrib/bb-perf/bb-matrix.sh | 12 +++++------- > > 1 file changed, 5 insertions(+), 7 deletions(-) > > > > diff --git a/scripts/contrib/bb-perf/bb-matrix.sh > > b/scripts/contrib/bb-perf/bb-matrix.sh > > index 37721fe..1064565 100755 > > --- a/scripts/contrib/bb-perf/bb-matrix.sh > > +++ b/scripts/contrib/bb-perf/bb-matrix.sh > > @@ -63,6 +63,10 @@ for BB in $BB_RANGE; do > > date > > echo "BB=$BB PM=$PM Logging to $BB_LOG" > > > > + echo -n " Preparing the work directory... " > > + rm -rf pseudodone tmp sstate-cache tmp-eglibc &> /dev/null > > + echo "done" > > + > > Makes sense to me, although there is one point worth discussing. The > tmp-eglibc directory could change depending on the DISTRO setting iiuc. > All of tmp, sstate-cache, and tmp-eglibc could be dealt with using > cleansstate I believe: > > bitbake <target> -c cleansstate > > Richard, should we consider using this instead?
Sadly this isn't recursive, it applies to <target> and not any dependencies of it. I'd be tempted to simplify this to rm tmp* and depend on a convention of calling them tmp*... Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
