[PATCH 0/4] meta: resend patches

[PATCH 0/4] meta: resend patches

[Robert Yang]

Hi RP and Ross,

I had sent these patches before, but didn't get any feedback, now send
again, would you please take a look at them ?

The following two patches would make oe-core can do world build well
without x11 in DISTRO_FEATURES:
gtk+/cairo: enable x11 or directfb
libsdl: depends on libglu when both x11 and opengl

And the patches for insane.bbclass will make package_qa_check_buildpaths
actually useful.

// Robert

The following changes since commit f0189829498e30231d826c9f55aad73e622d076e:

  qemu: Update to upstream patches (2015-09-14 11:22:02 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/resend
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/resend

Robert Yang (4):
  gtk+/cairo: enable x11 or directfb
  libsdl: depends on libglu when both x11 and opengl
  insane.bbclass: fix package_qa_check_buildpaths
  insane.bbclass: make package_qa_clean_path return a relative path

 meta/classes/insane.bbclass                   |   14 ++++++++++----
 meta/recipes-gnome/gtk+/gtk+.inc              |    5 ++---
 meta/recipes-graphics/cairo/cairo.inc         |    8 ++++++--
 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |    3 ++-
 4 files changed, 20 insertions(+), 10 deletions(-)

-- 
1.7.9.5

[PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Robert Yang]

The gtk+2 requires whether x11 or directfb to build, so we need enable
either of them. The cairo can be built without x11 or directfb, but gtk+
requires cairo, so enable x11 or directfb for cairo, too.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-gnome/gtk+/gtk+.inc      |    5 ++---
 meta/recipes-graphics/cairo/cairo.inc |    8 ++++++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index be5273d..9d697cdb 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -17,9 +17,8 @@ X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr libxdamage libxrender
 DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native docbook-utils-native \
  cairo gdk-pixbuf"
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
-           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
-"
+# Requires x11 or directfb
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'directfb', d)}"
 
 PACKAGECONFIG[x11] = "--with-x=yes --with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
 # without --with-gdktarget=directfb it will check for cairo-xlib which isn't available without X11 DISTRO_FEATURE
diff --git a/meta/recipes-graphics/cairo/cairo.inc b/meta/recipes-graphics/cairo/cairo.inc
index 1e45318..f6474bc 100644
--- a/meta/recipes-graphics/cairo/cairo.inc
+++ b/meta/recipes-graphics/cairo/cairo.inc
@@ -17,8 +17,12 @@ LICENSE_${PN}-perf-utils = "GPLv3+"
 X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
 DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb', '', d)} \
-           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)}"
+# Build cairo-xlib or cairo-directfb for gtk+
+PACKAGECONFIG ??= " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb', 'directfb', d)} \
+                    "
+
+# No directfb-native, so set PACKAGECONFIG to null when no x11
+PACKAGECONFIG_class-native ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
 
 PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no --disable-xlib,${X11DEPENDS}"
 PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
-- 
1.7.9.5

Re: [PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

On 16 September 2015 at 05:28, Robert Yang <liezhi.yang@windriver.com>
wrote:
>
> The gtk+2 requires whether x11 or directfb to build, so we need enable
> either of them. The cairo can be built without x11 or directfb, but gtk+
> requires cairo, so enable x11 or directfb for cairo, too.

What is the issue being fixed here? I can see how current config can go
wrong in some situations but I'm not sure if the approach "if x11 is not a
DISTRO_FEATURE, then automatically use direcfb" is much better. Especially
for cairo: I would have thought building multiple surface backends is a
valid choice there?

Jussi

> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>  meta/recipes-gnome/gtk+/gtk+.inc      |    5 ++---
>  meta/recipes-graphics/cairo/cairo.inc |    8 ++++++--
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-gnome/gtk+/gtk+.inc
b/meta/recipes-gnome/gtk+/gtk+.inc
> index be5273d..9d697cdb 100644
> --- a/meta/recipes-gnome/gtk+/gtk+.inc
> +++ b/meta/recipes-gnome/gtk+/gtk+.inc
> @@ -17,9 +17,8 @@ X11DEPENDS = "virtual/libx11 libxext libxcursor
libxrandr libxdamage libxrender
>  DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native
docbook-utils-native \
>   cairo gdk-pixbuf"
>
> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'', d)} \
> -           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)} \
> -"
> +# Requires x11 or directfb
> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'directfb', d)}"
>
>  PACKAGECONFIG[x11] = "--with-x=yes
--with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
>  # without --with-gdktarget=directfb it will check for cairo-xlib which
isn't available without X11 DISTRO_FEATURE
> diff --git a/meta/recipes-graphics/cairo/cairo.inc
b/meta/recipes-graphics/cairo/cairo.inc
> index 1e45318..f6474bc 100644
> --- a/meta/recipes-graphics/cairo/cairo.inc
> +++ b/meta/recipes-graphics/cairo/cairo.inc
> @@ -17,8 +17,12 @@ LICENSE_${PN}-perf-utils = "GPLv3+"
>  X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
>  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>
> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
xcb', '', d)} \
> -           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)}"
> +# Build cairo-xlib or cairo-directfb for gtk+
> +PACKAGECONFIG ??= " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
xcb', 'directfb', d)} \
> +                    "
> +
> +# No directfb-native, so set PACKAGECONFIG to null when no x11
> +PACKAGECONFIG_class-native ??= "${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', '', d)}"
>
>  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
--disable-xlib,${X11DEPENDS}"
>  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> --
> 1.7.9.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 4077 bytes --]

Re: [PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Robert Yang]

On 09/16/2015 06:25 PM, Jussi Kukkonen wrote:
> On 16 September 2015 at 05:28, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>  >
>  > The gtk+2 requires whether x11 or directfb to build, so we need enable
>  > either of them. The cairo can be built without x11 or directfb, but gtk+
>  > requires cairo, so enable x11 or directfb for cairo, too.
>
> What is the issue being fixed here? I can see how current config can go wrong in

Make the world build OK when possible, for example, when no x11 in
DISTRO_FEATURE.

> some situations but I'm not sure if the approach "if x11 is not a
> DISTRO_FEATURE, then automatically use direcfb" is much better. Especially for
> cairo: I would have thought building multiple surface backends is a valid choice
> there?

Yes, this is not a perfect solution, I don't like to pull in directfb either.
We can override PACKAGECONFIG to custom the build.

// Robert

>
> Jussi
>
>  > Signed-off-by: Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>>
>  > ---
>  >  meta/recipes-gnome/gtk+/gtk+.inc      |    5 ++---
>  >  meta/recipes-graphics/cairo/cairo.inc |    8 ++++++--
>  >  2 files changed, 8 insertions(+), 5 deletions(-)
>  >
>  > diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
>  > index be5273d..9d697cdb 100644
>  > --- a/meta/recipes-gnome/gtk+/gtk+.inc
>  > +++ b/meta/recipes-gnome/gtk+/gtk+.inc
>  > @@ -17,9 +17,8 @@ X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr
> libxdamage libxrender
>  >  DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native
> docbook-utils-native \
>  >   cairo gdk-pixbuf"
>  >
>  > -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '',
> d)} \
>  > -           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb',
> '', d)} \
>  > -"
>  > +# Requires x11 or directfb
>  > +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
> 'directfb', d)}"
>  >
>  >  PACKAGECONFIG[x11] = "--with-x=yes
> --with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
>  >  # without --with-gdktarget=directfb it will check for cairo-xlib which isn't
> available without X11 DISTRO_FEATURE
>  > diff --git a/meta/recipes-graphics/cairo/cairo.inc
> b/meta/recipes-graphics/cairo/cairo.inc
>  > index 1e45318..f6474bc 100644
>  > --- a/meta/recipes-graphics/cairo/cairo.inc
>  > +++ b/meta/recipes-graphics/cairo/cairo.inc
>  > @@ -17,8 +17,12 @@ LICENSE_${PN}-perf-utils = "GPLv3+"
>  >  X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
>  >  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>  >
>  > -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb',
> '', d)} \
>  > -           ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb',
> '', d)}"
>  > +# Build cairo-xlib or cairo-directfb for gtk+
>  > +PACKAGECONFIG ??= " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
> xcb', 'directfb', d)} \
>  > +                    "
>  > +
>  > +# No directfb-native, so set PACKAGECONFIG to null when no x11
>  > +PACKAGECONFIG_class-native ??= "${@bb.utils.contains('DISTRO_FEATURES',
> 'x11', 'x11', '', d)}"
>  >
>  >  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
> --disable-xlib,${X11DEPENDS}"
>  >  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
>  > --
>  > 1.7.9.5
>  >
>  > --
>  > _______________________________________________
>  > Openembedded-core mailing list
>  > Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
>  > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

On 16 September 2015 at 11:34, Robert Yang <liezhi.yang@windriver.com>
wrote:

> Make the world build OK when possible, for example, when no x11 in
> DISTRO_FEATURE.
>

But now you're just explicitly ignoring the directfb DISTRO_FEATURE.  Maybe
if you want to do a world build without X11 enabled the you should add
directfb to DISTRO_FEATURES?

Ross

[-- Attachment #2: Type: text/html, Size: 801 bytes --]

Re: [PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Robert Yang]

On 09/19/2015 04:23 AM, Burton, Ross wrote:
>
> On 16 September 2015 at 11:34, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>
>     Make the world build OK when possible, for example, when no x11 in
>     DISTRO_FEATURE.
>
>
> But now you're just explicitly ignoring the directfb DISTRO_FEATURE.  Maybe if
> you want to do a world build without X11 enabled the you should add directfb to
> DISTRO_FEATURES?

If I understand correctly, how about we add a sanity check when do world
build? Either X11 or directfb should be in DISTRO_FEATURES. But gtk+ is
the only one which requires this, others can be built without both of them.

// Robert

>
> Ross

Re: [PATCH 1/4] gtk+/cairo: enable x11 or directfb

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On 22 September 2015 at 03:40, Robert Yang <liezhi.yang@windriver.com>
wrote:

> If I understand correctly, how about we add a sanity check when do world
> build? Either X11 or directfb should be in DISTRO_FEATURES. But gtk+ is
> the only one which requires this, others can be built without both of them.
>

I don't think we need a sanity test for that.  If you want to do a world
build a limited set of DISTRO_FEATURES then we need to path in more
required_distro_features checks and/or you exclude recipes from world
builds (using EXCLUDE_FROM_WORLD).

Ross

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

[PATCH 2/4] libsdl: depends on libglu when both x11 and opengl

[Robert Yang]

The libglu requires both opengl (depends on virtual/libgl) and x11
(needs libGL.so which is provided by mesa when x11 in DISTRO_FEATURES),
so let libsdl depends on libglu when both x11 and opengl in
DISTRO_FEATURES.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index 266bd42..c0d5c6a 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -13,8 +13,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
 PROVIDES = "virtual/libsdl"
 
 DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
-           ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl libglu', '', d)} \
+           ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)} \
            ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext libxrandr libxrender', '', d)} \
+           ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'libglu', '', d)} \
            tslib"
 DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender nativesdk-libxext', '', d)}"
 
-- 
1.7.9.5

[PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

[Robert Yang]

* Ignore elf files because they usually contain build path:
  - The path of the source file such as .c, these are usually happen
    when separate B and S since we use absolute path to run configure
    script, and then VPATH in Makefile will be an absolute path and
    contains build path, we can use relative path in autotools.bbclass
    to fix the problem, but we don't have to since they are harmless.
  - The configure options such as "configure --with-libtool-sysroot"
  - The compile options such as "gcc --sysroot"
  These are harmless usually, so ignore elf files.

* Ignore "-dbg" and "-staticdev" package since symbols and .a files
  usually contain buildpath.

* Ignore .a files too since they contain buildpath, this mainly for
  ignoring:
  glibc-2.21: glibc-dev/usr/lib/libc_nonshared.a
  libgcc-4.9.3: libgcc-dev/usr/lib/x86_64-poky-linux/4.9.3/libgcc_eh.a
  gcc-runtime-4.9.3: libssp-dev/usr/lib/libssp_nonshared.a

* Use full path rather than package_qa_clean_path() when report issue,
  this makes it easier to find the file and fix the problem.

Then we will verify other warings and fix one be one.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/classes/insane.bbclass |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5c8629a..943ada8 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -571,8 +571,14 @@ def package_qa_check_buildpaths(path, name, d, elf, messages):
     """
     Check for build paths inside target files and error if not found in the whitelist
     """
-    # Ignore .debug files, not interesting
-    if path.find(".debug") != -1:
+
+    # Ignore staticdev and debug files since symbols and .a usually
+    # contain buildpath.
+    if name.endswith("-dbg") or name.endswith("-staticdev"):
+        return
+
+    # Ignore elf and .a files
+    if elf or path.endswith('.a'):
         return
 
     # Ignore symlinks
@@ -583,7 +589,7 @@ def package_qa_check_buildpaths(path, name, d, elf, messages):
     with open(path) as f:
         file_content = f.read()
         if tmpdir in file_content:
-            messages["buildpaths"] = "File %s in package contained reference to tmpdir" % package_qa_clean_path(path,d)
+            messages["buildpaths"] = "File %s in package contained reference to tmpdir" % path
 
 
 QAPATHTEST[xorg-driver-abi] = "package_qa_check_xorg_driver_abi"
-- 
1.7.9.5

Re: [PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

[Richard Purdie]

On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:
> * Ignore elf files because they usually contain build path:
>   - The path of the source file such as .c, these are usually happen
>     when separate B and S since we use absolute path to run configure
>     script, and then VPATH in Makefile will be an absolute path and
>     contains build path, we can use relative path in autotools.bbclass
>     to fix the problem, but we don't have to since they are harmless.
>   - The configure options such as "configure --with-libtool-sysroot"
>   - The compile options such as "gcc --sysroot"
>   These are harmless usually, so ignore elf files.

I'm not sure about this. Yes, elf files have large issues in the debug
symbols but the main elf files really shouldn't have build paths in
them. I understand they can creep in through a variety of sources
including B!=S but we should really be identifying them and fixing them,
not pretending they don't exist. The whole point of this check
originally was to get to the bottom of this!

> * Ignore "-dbg" and "-staticdev" package since symbols and .a files
>   usually contain buildpath.

Ideally, we should be fixing the debug code so its using target paths
rather than build ones too...

Cheers,

Richard

> * Ignore .a files too since they contain buildpath, this mainly for
>   ignoring:
>   glibc-2.21: glibc-dev/usr/lib/libc_nonshared.a
>   libgcc-4.9.3: libgcc-dev/usr/lib/x86_64-poky-linux/4.9.3/libgcc_eh.a
>   gcc-runtime-4.9.3: libssp-dev/usr/lib/libssp_nonshared.a
> 
> * Use full path rather than package_qa_clean_path() when report issue,
>   this makes it easier to find the file and fix the problem.
> 
> Then we will verify other warings and fix one be one.

Re: [PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

[Robert Yang]

On 09/16/2015 08:38 PM, Richard Purdie wrote:
> On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:
>> * Ignore elf files because they usually contain build path:
>>    - The path of the source file such as .c, these are usually happen
>>      when separate B and S since we use absolute path to run configure
>>      script, and then VPATH in Makefile will be an absolute path and
>>      contains build path, we can use relative path in autotools.bbclass
>>      to fix the problem, but we don't have to since they are harmless.
>>    - The configure options such as "configure --with-libtool-sysroot"
>>    - The compile options such as "gcc --sysroot"
>>    These are harmless usually, so ignore elf files.
>
> I'm not sure about this. Yes, elf files have large issues in the debug
> symbols but the main elf files really shouldn't have build paths in
> them. I understand they can creep in through a variety of sources
> including B!=S but we should really be identifying them and fixing them,
> not pretending they don't exist. The whole point of this check
> originally was to get to the bottom of this!

Thanks, the fix will change a lot to the build behaviour, I'd like to fix
them in 2.1.

// Robert

>
>> * Ignore "-dbg" and "-staticdev" package since symbols and .a files
>>    usually contain buildpath.
>
> Ideally, we should be fixing the debug code so its using target paths
> rather than build ones too...
>
> Cheers,
>
> Richard
>
>> * Ignore .a files too since they contain buildpath, this mainly for
>>    ignoring:
>>    glibc-2.21: glibc-dev/usr/lib/libc_nonshared.a
>>    libgcc-4.9.3: libgcc-dev/usr/lib/x86_64-poky-linux/4.9.3/libgcc_eh.a
>>    gcc-runtime-4.9.3: libssp-dev/usr/lib/libssp_nonshared.a
>>
>> * Use full path rather than package_qa_clean_path() when report issue,
>>    this makes it easier to find the file and fix the problem.
>>
>> Then we will verify other warings and fix one be one.
>
>
>
>

Re: [PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

[Richard Purdie]

On Wed, 2015-09-16 at 21:56 +0800, Robert Yang wrote:
> On 09/16/2015 08:38 PM, Richard Purdie wrote:
> > On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:
> >> * Ignore elf files because they usually contain build path:
> >>    - The path of the source file such as .c, these are usually happen
> >>      when separate B and S since we use absolute path to run configure
> >>      script, and then VPATH in Makefile will be an absolute path and
> >>      contains build path, we can use relative path in autotools.bbclass
> >>      to fix the problem, but we don't have to since they are harmless.
> >>    - The configure options such as "configure --with-libtool-sysroot"
> >>    - The compile options such as "gcc --sysroot"
> >>    These are harmless usually, so ignore elf files.
> >
> > I'm not sure about this. Yes, elf files have large issues in the debug
> > symbols but the main elf files really shouldn't have build paths in
> > them. I understand they can creep in through a variety of sources
> > including B!=S but we should really be identifying them and fixing them,
> > not pretending they don't exist. The whole point of this check
> > originally was to get to the bottom of this!
> 
> Thanks, the fix will change a lot to the build behaviour, I'd like to fix
> them in 2.1.

Agreed, this is 2.1 material at this point.

Cheers,

Richard

[PATCH 4/4] insane.bbclass: make package_qa_clean_path return a relative path

[Robert Yang]

Make package_qa_clean_path() return something like "work/path/to/file"
rather than "/work/path/to/file", the relative path is a little clear.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/classes/insane.bbclass |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 943ada8..628b63f 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -166,7 +166,7 @@ def package_qa_get_machine_dict():
 
 def package_qa_clean_path(path,d):
     """ Remove the common prefix from the path. In this case it is the TMPDIR"""
-    return path.replace(d.getVar('TMPDIR',True),"")
+    return path.replace(d.getVar("TMPDIR", True) + "/", "")
 
 def package_qa_write_error(type, error, d):
     logfile = d.getVar('QA_LOGFILE', True)
-- 
1.7.9.5