Re: [PATCH 1/1] package.bbclass: decouple splitting and stripping

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2015-03-13 at 23:50 +0100, Bernhard Reutner-Fischer wrote:
> On March 13, 2015 10:57:53 PM GMT+01:00, Joe Slater <jslater@windriver.com> wrote:
> >Fix logic in split_and_strip_files() to allow splitting or
> >stripping independently.  We also return quickly from this
> >function if we have nothing to do.  We seek the following behavior:
> >
> >Strip / Split     Behavior
> >yes   / yes       binaries stripped; debug info and source in -dbg
> >no    / yes       debug info and source in -dbg
> >yes   / no        binaries stripped; -dbg packages empty
> >no    / no        -dbg packages empty (not a very useful case)
> >
> >Currently, no/yes does not work and is the same as no/no.
> >
> >Signed-off-by: Joe Slater <jslater@windriver.com>
> >---
> >meta/classes/package.bbclass |  108
> >++++++++++++++++++++++--------------------
> > 1 file changed, 57 insertions(+), 51 deletions(-)
> >
> >diff --git a/meta/classes/package.bbclass
> >b/meta/classes/package.bbclass
> >index 9f64ed7..ad8771f 100644
> >--- a/meta/classes/package.bbclass
> >+++ b/meta/classes/package.bbclass
> >@@ -812,6 +812,12 @@ python fixup_perms () {
> > }
> > 
> > python split_and_strip_files () {
> 
> >+    for root, dirs, files in cpath.walk(dvar):
> >+        for f in files:
> >+            file = os.path.join(root, f)
> >+            if file.endswith(".ko") and file.find("/lib/modules/") !=
> >-1:
> >+                kernmods.append(file)
> >+                continue
> >  
> >+            # Skip debug files
> >+            if debugappend and file.endswith(debugappend):
> >+                continue
> >+            if debugdir and debugdir in
> >os.path.dirname(file[len(dvar):]):
> >+                continue
> >+
> 
> It's a pity to first construct the files just to throw them away right afterwards.
> Maybe there are other cpath.walk spots that would benefit from file_not_endswith and dir filters?

FWIW cpath is actually a caching wrapper around os.path so there is some
amount of caching going on here behind the scenes. The current code has
been profiled and the worst hot spots worked around with the cache...

Its not perfect and I don't doubt more could be done but these pieces do
seem to help a lot. The best thing we did is avoid a lot of syscall
overhead.

Cheers,

Richard