On Tue, 2018-05-22 at 13:36 +0100, Richard Purdie wrote: > On Tue, 2018-05-22 at 13:25 +0100, André Draszik wrote: > > diff --git a/meta/classes/sstate.bbclass > > b/meta/classes/sstate.bbclass > > index 1a95f8f2b9..e5b86ad705 100644 > > --- a/meta/classes/sstate.bbclass > > +++ b/meta/classes/sstate.bbclass > > @@ -897,6 +897,7 @@ def setscene_depvalid(task, taskdependees, > > notneeded, d, log=None): > > # task is included in taskdependees too > > # Return - False - We need this dependency > > # - True - We can skip this dependency > > + import re > > > > def logit(msg, log): > > if log is not None: > > @@ -957,6 +958,18 @@ def setscene_depvalid(task, taskdependees, > > notneeded, d, log=None): > > # Nothing need depend on libc-initial/gcc-cross-initial > > if "-initial" in taskdependees[task][0]: > > continue > > + # Allow excluding certain recursive dependencies. If a > > recipe needs it should add a > > + # specific dependency itself, rather than relying on one > > of its dependees to pull > > + # them in. > > + # See also http://lists.openembedded.org/pipermail/opene > > mbedded-core/2018-January/146324.html > > + not_needed = False > > + for excl in (d.getVar('SSTATE_EXCLUDEDEPS_SYSROOT') or > > "").split(): > > + if re.match(excl.split('->', 1)[0], > > taskdependees[dep][0]): > > + if re.match(excl.split('->', 1)[1], > > taskdependees[task][0]): > > + not_needed = True > > + break > > + if not_needed: > > + continue > > # For meta-extsdk-toolchain we want all sysroot > > dependencies > > if taskdependees[dep][0] == 'meta-extsdk-toolchain': > > return False > > Have you looked at the performance impact of this change? It looks like > it will be compiling the regexp each time inside a tight loop which > gets called once per task dependency which will show up significantly > on the performance chart.
True, and no, I haven't. Is there a good way to compare the performance with and without this change other than using 'time'? > We already have a "*" syntax used in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS > and I'd rather use that syntax here to avoid the use of re if we can > help it. Could you see if that is possible please? That would also keep > the syntax compatible. OK. Cheers, Andre' -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
