[PATCH 0/1] Fix overriding PACKAGE_ARCH for MACHINE specific SRC_URI

[PATCH 0/1] Fix overriding PACKAGE_ARCH for MACHINE specific SRC_URI

[Joshua Lock]

After the discussion following my recent netbase patch I spent some time today
looking to fixup the BSP which triggered the change and discovered that the
logic to set PACKAGE_ARCH = MACHINE_ARCH for MACHINE specific SRC_URI overrides
doesn't search for said overrides in layers.

This patch is probably an ugly fix, but it's a fix nonetheless. I couldn't find
a better fix before boarding a plane so submit this as is for review.

Cheers,
Joshua

The following changes since commit 41a83ccfe50ec69425a4828fb5836d38d3f99e67:

  guile: fix cross configure failure (2012-02-10 17:01:42 +0000)

are available in the git repository at:
  git://git.yoctoproject.org/poky-contrib josh/work
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=josh/work

Joshua Lock (1):
  base.bbclass: look in layers for SRC_URI with MACHINE overrides too

 meta/classes/base.bbclass |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

-- 
1.7.7.6

[PATCH 1/1] base.bbclass: look in layers for SRC_URI with MACHINE overrides too

[Joshua Lock]

The logic which looks for MACHINE overrides in SRC_URI and updates PACKAGE_ARCH
accordingly doesn't account for SRC_URI overrides in layers.

This patch may not be the cleanest approach to solving the issue but it works.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/classes/base.bbclass |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a26ac94..8fd5e53 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -460,6 +460,16 @@ python () {
             path = bb.data.expand(os.path.join("${FILE_DIRNAME}", p, "${MACHINE}"), d)
             if os.path.isdir(path):
                 paths.append(path)
+
+        # FILE is relative to the original recipe, for any bbappends in
+        # layers we need to look a little further
+        expaths = d.getVar('FILESEXTRAPATHS', True) or ""
+        for path in expaths.split(":"):
+            if len(path):
+                p = bb.data.expand(os.path.join(path, "${MACHINE}"), d)
+                if os.path.isdir(p):
+	            paths.append(p)
+
         if len(paths) != 0:
             for s in srcuri.split():
                 if not s.startswith("file://"):
-- 
1.7.7.6

Re: [PATCH 1/1] base.bbclass: look in layers for SRC_URI with MACHINE overrides too

[Otavio Salvador]

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

On Fri, Feb 10, 2012 at 22:30, Joshua Lock <josh@linux.intel.com> wrote:

> The logic which looks for MACHINE overrides in SRC_URI and updates
> PACKAGE_ARCH
> accordingly doesn't account for SRC_URI overrides in layers.
>

It seems to address the issue but I think we need to support bbappend with
overrides. If the layer doesn't use a machine override, then:

 * it is not machine depdendant, or
 * is a bug in the layer

People agree with this point of view?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

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

Re: [PATCH 1/1] base.bbclass: look in layers for SRC_URI with MACHINE overrides too

[Joshua Lock]

On 11/02/12 05:02, Otavio Salvador wrote:
> On Fri, Feb 10, 2012 at 22:30, Joshua Lock <josh@linux.intel.com
> <mailto:josh@linux.intel.com>> wrote:
>
>     The logic which looks for MACHINE overrides in SRC_URI and updates
>     PACKAGE_ARCH
>     accordingly doesn't account for SRC_URI overrides in layers.
>
>
> It seems to address the issue but I think we need to support bbappend
> with overrides.

Agreed, this patch adds hacky support for that. I am working on a more 
suitable patch to do this in a cleaner way.

If the layer doesn't use a machine override, then:
>
>   * it is not machine depdendant, or
>   * is a bug in the layer
>
> People agree with this point of view?

I do.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre