[PATCH] utils.bbclass: Fix override ordering for FILESPATH

[PATCH] utils.bbclass: Fix override ordering for FILESPATH

[Richard Purdie]

Currently the overrides are being applied backwards. This means something which is
platform specific is overriding something which is machine specific which
is clearly not intended.

This patch corrects the ordering to match the normal expected behaviour of
OVERRIDES.

Secondly, all overrides are being searched for each path in turn. What should
really happen is that we should look for the highest priority override (e.g. distro
or machine) in each layer, then move on to platform/tune (e.g. armv7a) and
then to arch (e.g. arm). This patch therefore also reverses the for loops
to achieve this behaviour and give the result the user would expect.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index d1f6563..0a533af 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -307,10 +307,11 @@ def base_set_filespath(path, d):
     if extrapaths != "":
         path = extrapaths.split(":") + path
     # The ":" ensures we have an 'empty' override
-    overrides = ((d.getVar("FILESOVERRIDES", True) or "") + ":").split(":")
-    for p in path:
-        if p != "": 
-            for o in overrides:
+    overrides = (":" + (d.getVar("FILESOVERRIDES", True) or "")).split(":")
+    overrides.reverse()
+    for o in overrides:
+        for p in path:
+            if p != "": 
                 filespath.append(os.path.join(p, o))
     return ":".join(filespath)
 

SRC_URI computing order

[Eric Bénard]

Hi Richard,

I saw your patch fixing FILESPATH's and Kergoth's one fixing
PACKAGECONFIG processing order and I think I'm also facing an order
problem when SRC_URI is computed.

So when building SRC_URI when two layers have bbappend which apply
patches : the SRC_URI seems to be built using an order I fail to
understand somewhere instead of priority or the overrides' order.

The use case is a System on Module and its custom motherboard :
- meta-fsl-arm :
* linux-imx_xyz.bb :
SRC_URI = "patchgeneric1 ..."

- meta-som-support :
* conf/machine/mysom.conf

* linux-imx_xyz.bbappend :
SRC_URI_append_mysom = "patchsom1 patchsom2 ..."

- meta-custommotherboard (SOM + Cunstom Motherboard) :
* conf/machine/myproduct.conf
MACHINEOVERRIDES_prepend = "mysom:"
include conf/machine/mysom.conf

* linux-imx_xyz.bbappend :
SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."

in the end I get :
SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
patchsom1 ..."

and of course as patchproduct* are supposed to apply on top of
patchsoc* the patch fail to apply.

I didn't found a way to build SRC_URI in the order I would like (I
tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
changing machine's name to see if that was an alphabetical order ...).

In the end the only thing which worked was to add an (empty by default)
variable in som's SRC_URI and filling this variables from the
custommotherboard's bbappend.

Is the behaviour I'm seeing expected or is there something wrong in my
setup ?

Thanks,
Eric

Re: SRC_URI computing order

[Khem Raj]

On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Richard,
>
> I saw your patch fixing FILESPATH's and Kergoth's one fixing
> PACKAGECONFIG processing order and I think I'm also facing an order
> problem when SRC_URI is computed.
>
> So when building SRC_URI when two layers have bbappend which apply
> patches : the SRC_URI seems to be built using an order I fail to
> understand somewhere instead of priority or the overrides' order.
>
> The use case is a System on Module and its custom motherboard :
> - meta-fsl-arm :
> * linux-imx_xyz.bb :
> SRC_URI = "patchgeneric1 ..."
>
> - meta-som-support :
> * conf/machine/mysom.conf
>
> * linux-imx_xyz.bbappend :
> SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>
> - meta-custommotherboard (SOM + Cunstom Motherboard) :
> * conf/machine/myproduct.conf
> MACHINEOVERRIDES_prepend = "mysom:"
> include conf/machine/mysom.conf
>
> * linux-imx_xyz.bbappend :
> SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>
> in the end I get :
> SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> patchsom1 ..."
>
> and of course as patchproduct* are supposed to apply on top of
> patchsoc* the patch fail to apply.
>
> I didn't found a way to build SRC_URI in the order I would like (I
> tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> changing machine's name to see if that was an alphabetical order ...).
>
> In the end the only thing which worked was to add an (empty by default)
> variable in som's SRC_URI and filling this variables from the
> custommotherboard's bbappend.
>
> Is the behaviour I'm seeing expected or is there something wrong in my
> setup ?

what is your OVERRIDES order.

>
> Thanks,
> Eric
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: SRC_URI computing order

[Eric Bénard]

Hi Khem,

Le Mon, 28 Oct 2013 20:45:21 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :

> On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Hi Richard,
> >
> > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> > PACKAGECONFIG processing order and I think I'm also facing an order
> > problem when SRC_URI is computed.
> >
> > So when building SRC_URI when two layers have bbappend which apply
> > patches : the SRC_URI seems to be built using an order I fail to
> > understand somewhere instead of priority or the overrides' order.
> >
> > The use case is a System on Module and its custom motherboard :
> > - meta-fsl-arm :
> > * linux-imx_xyz.bb :
> > SRC_URI = "patchgeneric1 ..."
> >
> > - meta-som-support :
> > * conf/machine/mysom.conf
> >
> > * linux-imx_xyz.bbappend :
> > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> >
> > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> > * conf/machine/myproduct.conf
> > MACHINEOVERRIDES_prepend = "mysom:"
> > include conf/machine/mysom.conf
> >
> > * linux-imx_xyz.bbappend :
> > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> >
> > in the end I get :
> > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> > patchsom1 ..."
> >
> > and of course as patchproduct* are supposed to apply on top of
> > patchsoc* the patch fail to apply.
> >
> > I didn't found a way to build SRC_URI in the order I would like (I
> > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> > changing machine's name to see if that was an alphabetical order ...).
> >
> > In the end the only thing which worked was to add an (empty by default)
> > variable in som's SRC_URI and filling this variables from the
> > custommotherboard's bbappend.
> >
> > Is the behaviour I'm seeing expected or is there something wrong in my
> > setup ?
> 
> what is your OVERRIDES order.
> 
"${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"

so it follows the MACHINEOVERRIDES order (and I tried both append and
prepend to hack MACHINEOVERRIDES without any behaviour change).

Eric

Re: SRC_URI computing order

[Richard Purdie]

On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
> Hi Khem,
> 
> Le Mon, 28 Oct 2013 20:45:21 -0700,
> Khem Raj <raj.khem@gmail.com> a écrit :
> 
> > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
> > > Hi Richard,
> > >
> > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> > > PACKAGECONFIG processing order and I think I'm also facing an order
> > > problem when SRC_URI is computed.
> > >
> > > So when building SRC_URI when two layers have bbappend which apply
> > > patches : the SRC_URI seems to be built using an order I fail to
> > > understand somewhere instead of priority or the overrides' order.
> > >
> > > The use case is a System on Module and its custom motherboard :
> > > - meta-fsl-arm :
> > > * linux-imx_xyz.bb :
> > > SRC_URI = "patchgeneric1 ..."
> > >
> > > - meta-som-support :
> > > * conf/machine/mysom.conf
> > >
> > > * linux-imx_xyz.bbappend :
> > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> > >
> > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> > > * conf/machine/myproduct.conf
> > > MACHINEOVERRIDES_prepend = "mysom:"
> > > include conf/machine/mysom.conf
> > >
> > > * linux-imx_xyz.bbappend :
> > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> > >
> > > in the end I get :
> > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> > > patchsom1 ..."
> > >
> > > and of course as patchproduct* are supposed to apply on top of
> > > patchsoc* the patch fail to apply.
> > >
> > > I didn't found a way to build SRC_URI in the order I would like (I
> > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> > > changing machine's name to see if that was an alphabetical order ...).
> > >
> > > In the end the only thing which worked was to add an (empty by default)
> > > variable in som's SRC_URI and filling this variables from the
> > > custommotherboard's bbappend.
> > >
> > > Is the behaviour I'm seeing expected or is there something wrong in my
> > > setup ?
> > 
> > what is your OVERRIDES order.
> > 
> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
> 
> so it follows the MACHINEOVERRIDES order (and I tried both append and
> prepend to hack MACHINEOVERRIDES without any behaviour change).

I think what Khem is asking is what OVERRIDES expands to?

You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
patchsoc2?

Its hard to follow and it might be easier if you could share a
simplified test case we could reproduce this with. I don't doubt there
is an issue in there but we need a way to reproduce and debug this.

Cheers,

Richard

Re: SRC_URI computing order

[Eric Bénard]

Hi,

Le Mon, 28 Oct 2013 15:10:04 +0100,
Eric Bénard <eric@eukrea.com> a écrit :
> I saw your patch fixing FILESPATH's and Kergoth's one fixing
> PACKAGECONFIG processing order and I think I'm also facing an order
> problem when SRC_URI is computed.
> 
> So when building SRC_URI when two layers have bbappend which apply
> patches : the SRC_URI seems to be built using an order I fail to
> understand somewhere instead of priority or the overrides' order.
> 
> The use case is a System on Module and its custom motherboard :
> - meta-fsl-arm :
> * linux-imx_xyz.bb :
> SRC_URI = "patchgeneric1 ..."
> 
> - meta-som-support :
> * conf/machine/mysom.conf
> 
> * linux-imx_xyz.bbappend :
> SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> 
> - meta-custommotherboard (SOM + Cunstom Motherboard) :
> * conf/machine/myproduct.conf
> MACHINEOVERRIDES_prepend = "mysom:"
> include conf/machine/mysom.conf
> 
> * linux-imx_xyz.bbappend :
> SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> 
> in the end I get :
> SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> patchsom1 ..."
> 
> and of course as patchproduct* are supposed to apply on top of
> patchsoc* the patch fail to apply.
> 
> I didn't found a way to build SRC_URI in the order I would like (I
> tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> changing machine's name to see if that was an alphabetical order ...).
> 
> In the end the only thing which worked was to add an (empty by default)
> variable in som's SRC_URI and filling this variables from the
> custommotherboard's bbappend.
> 
> Is the behaviour I'm seeing expected or is there something wrong in my
> setup ?
> 
do you need more details concerning this problem ?

Thanks
Eric

Re: SRC_URI computing order

[Richard Purdie]

On Fri, 2013-11-01 at 16:36 +0100, Eric Bénard wrote:
> Hi,
> 
> Le Mon, 28 Oct 2013 15:10:04 +0100,
> Eric Bénard <eric@eukrea.com> a écrit :
> > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> > PACKAGECONFIG processing order and I think I'm also facing an order
> > problem when SRC_URI is computed.
> > 
> > So when building SRC_URI when two layers have bbappend which apply
> > patches : the SRC_URI seems to be built using an order I fail to
> > understand somewhere instead of priority or the overrides' order.
> > 
> > The use case is a System on Module and its custom motherboard :
> > - meta-fsl-arm :
> > * linux-imx_xyz.bb :
> > SRC_URI = "patchgeneric1 ..."
> > 
> > - meta-som-support :
> > * conf/machine/mysom.conf
> > 
> > * linux-imx_xyz.bbappend :
> > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> > 
> > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> > * conf/machine/myproduct.conf
> > MACHINEOVERRIDES_prepend = "mysom:"
> > include conf/machine/mysom.conf
> > 
> > * linux-imx_xyz.bbappend :
> > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> > 
> > in the end I get :
> > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> > patchsom1 ..."
> > 
> > and of course as patchproduct* are supposed to apply on top of
> > patchsoc* the patch fail to apply.
> > 
> > I didn't found a way to build SRC_URI in the order I would like (I
> > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> > changing machine's name to see if that was an alphabetical order ...).
> > 
> > In the end the only thing which worked was to add an (empty by default)
> > variable in som's SRC_URI and filling this variables from the
> > custommotherboard's bbappend.
> > 
> > Is the behaviour I'm seeing expected or is there something wrong in my
> > setup ?
> > 
> do you need more details concerning this problem ?

I sent a reply asking for more info. I think there is a typo above which
isn't helping...

Cheers,

Richard

Re: SRC_URI computing order

[Eric Bénard]

Le Fri, 01 Nov 2013 18:16:18 +0000,
Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :

> On Fri, 2013-11-01 at 16:36 +0100, Eric Bénard wrote:
> > Hi,
> > 
> > Le Mon, 28 Oct 2013 15:10:04 +0100,
> > Eric Bénard <eric@eukrea.com> a écrit :
> > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> > > PACKAGECONFIG processing order and I think I'm also facing an order
> > > problem when SRC_URI is computed.
> > > 
> > > So when building SRC_URI when two layers have bbappend which apply
> > > patches : the SRC_URI seems to be built using an order I fail to
> > > understand somewhere instead of priority or the overrides' order.
> > > 
> > > The use case is a System on Module and its custom motherboard :
> > > - meta-fsl-arm :
> > > * linux-imx_xyz.bb :
> > > SRC_URI = "patchgeneric1 ..."
> > > 
> > > - meta-som-support :
> > > * conf/machine/mysom.conf
> > > 
> > > * linux-imx_xyz.bbappend :
> > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> > > 
> > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> > > * conf/machine/myproduct.conf
> > > MACHINEOVERRIDES_prepend = "mysom:"
> > > include conf/machine/mysom.conf
> > > 
> > > * linux-imx_xyz.bbappend :
> > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> > > 
> > > in the end I get :
> > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> > > patchsom1 ..."
> > > 
> > > and of course as patchproduct* are supposed to apply on top of
> > > patchsoc* the patch fail to apply.
> > > 
> > > I didn't found a way to build SRC_URI in the order I would like (I
> > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> > > changing machine's name to see if that was an alphabetical order ...).
> > > 
> > > In the end the only thing which worked was to add an (empty by default)
> > > variable in som's SRC_URI and filling this variables from the
> > > custommotherboard's bbappend.
> > > 
> > > Is the behaviour I'm seeing expected or is there something wrong in my
> > > setup ?
> > > 
> > do you need more details concerning this problem ?
> 
> I sent a reply asking for more info. I think there is a typo above which
> isn't helping...
> 
sorry I missed your mail.

Eric

Re: SRC_URI computing order

[Eric Bénard]

Hi Richard,

Le Wed, 30 Oct 2013 15:15:12 +0000,
Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :

> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
> > Hi Khem,
> > 
> > Le Mon, 28 Oct 2013 20:45:21 -0700,
> > Khem Raj <raj.khem@gmail.com> a écrit :
> > 
> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
> > > > Hi Richard,
> > > >
> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> > > > PACKAGECONFIG processing order and I think I'm also facing an order
> > > > problem when SRC_URI is computed.
> > > >
> > > > So when building SRC_URI when two layers have bbappend which apply
> > > > patches : the SRC_URI seems to be built using an order I fail to
> > > > understand somewhere instead of priority or the overrides' order.
> > > >
> > > > The use case is a System on Module and its custom motherboard :
> > > > - meta-fsl-arm :
> > > > * linux-imx_xyz.bb :
> > > > SRC_URI = "patchgeneric1 ..."
> > > >
> > > > - meta-som-support :
> > > > * conf/machine/mysom.conf
> > > >
> > > > * linux-imx_xyz.bbappend :
> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> > > >
> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> > > > * conf/machine/myproduct.conf
> > > > MACHINEOVERRIDES_prepend = "mysom:"
> > > > include conf/machine/mysom.conf
> > > >
> > > > * linux-imx_xyz.bbappend :
> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> > > >
> > > > in the end I get :
> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> > > > patchsom1 ..."
> > > >
> > > > and of course as patchproduct* are supposed to apply on top of
> > > > patchsoc* the patch fail to apply.
> > > >
> > > > I didn't found a way to build SRC_URI in the order I would like (I
> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> > > > changing machine's name to see if that was an alphabetical order ...).
> > > >
> > > > In the end the only thing which worked was to add an (empty by default)
> > > > variable in som's SRC_URI and filling this variables from the
> > > > custommotherboard's bbappend.
> > > >
> > > > Is the behaviour I'm seeing expected or is there something wrong in my
> > > > setup ?
> > > 
> > > what is your OVERRIDES order.
> > > 
> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
> > 
> > so it follows the MACHINEOVERRIDES order (and I tried both append and
> > prepend to hack MACHINEOVERRIDES without any behaviour change).
> 
> I think what Khem is asking is what OVERRIDES expands to?
> 
> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
> patchsoc2?
> 
oops :
I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
and I get :
SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."

> Its hard to follow and it might be easier if you could share a
> simplified test case we could reproduce this with. I don't doubt there
> is an issue in there but we need a way to reproduce and debug this.
> 
OK, I'm preparing a simple testcase to reproduce that with oe-core +
meta-fsl-arm + meta-som + meta-baseboard.

Eric

Re: SRC_URI computing order

[Andrea Adami]

On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Richard,
>
> Le Wed, 30 Oct 2013 15:15:12 +0000,
> Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
>
>> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>> > Hi Khem,
>> >
>> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>> > Khem Raj <raj.khem@gmail.com> a écrit :
>> >
>> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > > > Hi Richard,
>> > > >
>> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>> > > > problem when SRC_URI is computed.
>> > > >
>> > > > So when building SRC_URI when two layers have bbappend which apply
>> > > > patches : the SRC_URI seems to be built using an order I fail to
>> > > > understand somewhere instead of priority or the overrides' order.
>> > > >
>> > > > The use case is a System on Module and its custom motherboard :
>> > > > - meta-fsl-arm :
>> > > > * linux-imx_xyz.bb :
>> > > > SRC_URI = "patchgeneric1 ..."
>> > > >
>> > > > - meta-som-support :
>> > > > * conf/machine/mysom.conf
>> > > >
>> > > > * linux-imx_xyz.bbappend :
>> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>> > > >
>> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>> > > > * conf/machine/myproduct.conf
>> > > > MACHINEOVERRIDES_prepend = "mysom:"
>> > > > include conf/machine/mysom.conf
>> > > >
>> > > > * linux-imx_xyz.bbappend :
>> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>> > > >
>> > > > in the end I get :
>> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>> > > > patchsom1 ..."
>> > > >
>> > > > and of course as patchproduct* are supposed to apply on top of
>> > > > patchsoc* the patch fail to apply.
>> > > >
>> > > > I didn't found a way to build SRC_URI in the order I would like (I
>> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
>> > > > changing machine's name to see if that was an alphabetical order ...).
>> > > >
>> > > > In the end the only thing which worked was to add an (empty by default)
>> > > > variable in som's SRC_URI and filling this variables from the
>> > > > custommotherboard's bbappend.
>> > > >
>> > > > Is the behaviour I'm seeing expected or is there something wrong in my
>> > > > setup ?
>> > >
>> > > what is your OVERRIDES order.
>> > >
>> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>> >
>> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>>
>> I think what Khem is asking is what OVERRIDES expands to?
>>
>> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>> patchsoc2?
>>
> oops :
> I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
> and I get :
> SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>
>> Its hard to follow and it might be easier if you could share a
>> simplified test case we could reproduce this with. I don't doubt there
>> is an issue in there but we need a way to reproduce and debug this.
>>
> OK, I'm preparing a simple testcase to reproduce that with oe-core +
> meta-fsl-arm + meta-som + meta-baseboard.
>
> Eric
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


I have to report an undesiderate behavior:

the formfactor files in our .bbappend are not considered :/
DEBUG: Searching for machconfig in paths:....
  /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
  /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
  /oe/oe-core/meta/recipes-bsp/formfactor/files/
  /oe/meta-handheld/recipes-bsp/formfactor/files/poodle

so we end up with the empty machconfig of
/oe/oe-core/meta/recipes-bsp/formfactor/files/

Surely this didn't happen when we tested the recipe.

Cheers

Andrea

Re: SRC_URI computing order

[Richard Purdie]

On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Hi Richard,
> >
> > Le Wed, 30 Oct 2013 15:15:12 +0000,
> > Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
> >
> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
> >> > Hi Khem,
> >> >
> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
> >> > Khem Raj <raj.khem@gmail.com> a écrit :
> >> >
> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
> >> > > > Hi Richard,
> >> > > >
> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
> >> > > > problem when SRC_URI is computed.
> >> > > >
> >> > > > So when building SRC_URI when two layers have bbappend which apply
> >> > > > patches : the SRC_URI seems to be built using an order I fail to
> >> > > > understand somewhere instead of priority or the overrides' order.
> >> > > >
> >> > > > The use case is a System on Module and its custom motherboard :
> >> > > > - meta-fsl-arm :
> >> > > > * linux-imx_xyz.bb :
> >> > > > SRC_URI = "patchgeneric1 ..."
> >> > > >
> >> > > > - meta-som-support :
> >> > > > * conf/machine/mysom.conf
> >> > > >
> >> > > > * linux-imx_xyz.bbappend :
> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
> >> > > >
> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
> >> > > > * conf/machine/myproduct.conf
> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
> >> > > > include conf/machine/mysom.conf
> >> > > >
> >> > > > * linux-imx_xyz.bbappend :
> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
> >> > > >
> >> > > > in the end I get :
> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> >> > > > patchsom1 ..."
> >> > > >
> >> > > > and of course as patchproduct* are supposed to apply on top of
> >> > > > patchsoc* the patch fail to apply.
> >> > > >
> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> >> > > > changing machine's name to see if that was an alphabetical order ...).
> >> > > >
> >> > > > In the end the only thing which worked was to add an (empty by default)
> >> > > > variable in som's SRC_URI and filling this variables from the
> >> > > > custommotherboard's bbappend.
> >> > > >
> >> > > > Is the behaviour I'm seeing expected or is there something wrong in my
> >> > > > setup ?
> >> > >
> >> > > what is your OVERRIDES order.
> >> > >
> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
> >> >
> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
> >>
> >> I think what Khem is asking is what OVERRIDES expands to?
> >>
> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
> >> patchsoc2?
> >>
> > oops :
> > I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
> > and I get :
> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
> >
> >> Its hard to follow and it might be easier if you could share a
> >> simplified test case we could reproduce this with. I don't doubt there
> >> is an issue in there but we need a way to reproduce and debug this.
> >>
> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
> > meta-fsl-arm + meta-som + meta-baseboard.
> >
> > Eric
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> I have to report an undesiderate behavior:
> 
> the formfactor files in our .bbappend are not considered :/
> DEBUG: Searching for machconfig in paths:....
>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
> 
> so we end up with the empty machconfig of
> /oe/oe-core/meta/recipes-bsp/formfactor/files/
> 
> Surely this didn't happen when we tested the recipe.

With which revision of OE-Core? Was this with the dora release tag,
current dora head or master?

Cheers,

Richard

Re: SRC_URI computing order

[Eric Bénard]

Hi Andrea,

Le Sun, 3 Nov 2013 23:16:09 +0100,
Andrea Adami <andrea.adami@gmail.com> a écrit :
> I have to report an undesiderate behavior:
> 
> the formfactor files in our .bbappend are not considered :/
> DEBUG: Searching for machconfig in paths:....
>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
> 
> so we end up with the empty machconfig of
> /oe/oe-core/meta/recipes-bsp/formfactor/files/
> 
> Surely this didn't happen when we tested the recipe.
> 
isn't that problem fixed by cherry-picking commit
92cbf7eeea553bfa24c7081473fa8bc4ebc1f552 in oe-core ?

Eric

Re: SRC_URI computing order

[Andrea Adami]

On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > Hi Richard,
>> >
>> > Le Wed, 30 Oct 2013 15:15:12 +0000,
>> > Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
>> >
>> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>> >> > Hi Khem,
>> >> >
>> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>> >> > Khem Raj <raj.khem@gmail.com> a écrit :
>> >> >
>> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
>> >> > > > Hi Richard,
>> >> > > >
>> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>> >> > > > problem when SRC_URI is computed.
>> >> > > >
>> >> > > > So when building SRC_URI when two layers have bbappend which apply
>> >> > > > patches : the SRC_URI seems to be built using an order I fail to
>> >> > > > understand somewhere instead of priority or the overrides' order.
>> >> > > >
>> >> > > > The use case is a System on Module and its custom motherboard :
>> >> > > > - meta-fsl-arm :
>> >> > > > * linux-imx_xyz.bb :
>> >> > > > SRC_URI = "patchgeneric1 ..."
>> >> > > >
>> >> > > > - meta-som-support :
>> >> > > > * conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>> >> > > >
>> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>> >> > > > * conf/machine/myproduct.conf
>> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
>> >> > > > include conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>> >> > > >
>> >> > > > in the end I get :
>> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>> >> > > > patchsom1 ..."
>> >> > > >
>> >> > > > and of course as patchproduct* are supposed to apply on top of
>> >> > > > patchsoc* the patch fail to apply.
>> >> > > >
>> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
>> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
>> >> > > > changing machine's name to see if that was an alphabetical order ...).
>> >> > > >
>> >> > > > In the end the only thing which worked was to add an (empty by default)
>> >> > > > variable in som's SRC_URI and filling this variables from the
>> >> > > > custommotherboard's bbappend.
>> >> > > >
>> >> > > > Is the behaviour I'm seeing expected or is there something wrong in my
>> >> > > > setup ?
>> >> > >
>> >> > > what is your OVERRIDES order.
>> >> > >
>> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>> >> >
>> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>> >>
>> >> I think what Khem is asking is what OVERRIDES expands to?
>> >>
>> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>> >> patchsoc2?
>> >>
>> > oops :
>> > I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
>> > and I get :
>> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>> >
>> >> Its hard to follow and it might be easier if you could share a
>> >> simplified test case we could reproduce this with. I don't doubt there
>> >> is an issue in there but we need a way to reproduce and debug this.
>> >>
>> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
>> > meta-fsl-arm + meta-som + meta-baseboard.
>> >
>> > Eric
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>> I have to report an undesiderate behavior:
>>
>> the formfactor files in our .bbappend are not considered :/
>> DEBUG: Searching for machconfig in paths:....
>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>>
>> so we end up with the empty machconfig of
>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>
>> Surely this didn't happen when we tested the recipe.
>
> With which revision of OE-Core? Was this with the dora release tag,
> current dora head or master?
>
> Cheers,
>
> Richard
>
>

This was with fresh master:

Build Configuration:
BB_VERSION        = "1.21.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "Gentoo"
TARGET_SYS        = "arm-oe-linux-gnueabi"
MACHINE           = "poodle"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "armv5 thumb dsp"
TARGET_FPU        = "soft"
meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"

Cheers

Re: [OE-core] SRC_URI computing order

[Andrea Adami]

On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > Hi Richard,
>> >
>> > Le Wed, 30 Oct 2013 15:15:12 +0000,
>> > Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
>> >
>> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>> >> > Hi Khem,
>> >> >
>> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>> >> > Khem Raj <raj.khem@gmail.com> a écrit :
>> >> >
>> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
>> >> > > > Hi Richard,
>> >> > > >
>> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>> >> > > > problem when SRC_URI is computed.
>> >> > > >
>> >> > > > So when building SRC_URI when two layers have bbappend which apply
>> >> > > > patches : the SRC_URI seems to be built using an order I fail to
>> >> > > > understand somewhere instead of priority or the overrides' order.
>> >> > > >
>> >> > > > The use case is a System on Module and its custom motherboard :
>> >> > > > - meta-fsl-arm :
>> >> > > > * linux-imx_xyz.bb :
>> >> > > > SRC_URI = "patchgeneric1 ..."
>> >> > > >
>> >> > > > - meta-som-support :
>> >> > > > * conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>> >> > > >
>> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>> >> > > > * conf/machine/myproduct.conf
>> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
>> >> > > > include conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>> >> > > >
>> >> > > > in the end I get :
>> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>> >> > > > patchsom1 ..."
>> >> > > >
>> >> > > > and of course as patchproduct* are supposed to apply on top of
>> >> > > > patchsoc* the patch fail to apply.
>> >> > > >
>> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
>> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
>> >> > > > changing machine's name to see if that was an alphabetical order ...).
>> >> > > >
>> >> > > > In the end the only thing which worked was to add an (empty by default)
>> >> > > > variable in som's SRC_URI and filling this variables from the
>> >> > > > custommotherboard's bbappend.
>> >> > > >
>> >> > > > Is the behaviour I'm seeing expected or is there something wrong in my
>> >> > > > setup ?
>> >> > >
>> >> > > what is your OVERRIDES order.
>> >> > >
>> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>> >> >
>> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>> >>
>> >> I think what Khem is asking is what OVERRIDES expands to?
>> >>
>> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>> >> patchsoc2?
>> >>
>> > oops :
>> > I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
>> > and I get :
>> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>> >
>> >> Its hard to follow and it might be easier if you could share a
>> >> simplified test case we could reproduce this with. I don't doubt there
>> >> is an issue in there but we need a way to reproduce and debug this.
>> >>
>> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
>> > meta-fsl-arm + meta-som + meta-baseboard.
>> >
>> > Eric
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>> I have to report an undesiderate behavior:
>>
>> the formfactor files in our .bbappend are not considered :/
>> DEBUG: Searching for machconfig in paths:....
>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>>
>> so we end up with the empty machconfig of
>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>
>> Surely this didn't happen when we tested the recipe.
>
> With which revision of OE-Core? Was this with the dora release tag,
> current dora head or master?
>
> Cheers,
>
> Richard
>
>

This was with fresh master:

Build Configuration:
BB_VERSION        = "1.21.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "Gentoo"
TARGET_SYS        = "arm-oe-linux-gnueabi"
MACHINE           = "poodle"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "armv5 thumb dsp"
TARGET_FPU        = "soft"
meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"

Cheers

Re: SRC_URI computing order

[Andrea Adami]

On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>>> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
>>> > Hi Richard,
>>> >
>>> > Le Wed, 30 Oct 2013 15:15:12 +0000,
>>> > Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
>>> >
>>> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>>> >> > Hi Khem,
>>> >> >
>>> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>>> >> > Khem Raj <raj.khem@gmail.com> a écrit :
>>> >> >
>>> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
>>> >> > > > Hi Richard,
>>> >> > > >
>>> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>>> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>>> >> > > > problem when SRC_URI is computed.
>>> >> > > >
>>> >> > > > So when building SRC_URI when two layers have bbappend which apply
>>> >> > > > patches : the SRC_URI seems to be built using an order I fail to
>>> >> > > > understand somewhere instead of priority or the overrides' order.
>>> >> > > >
>>> >> > > > The use case is a System on Module and its custom motherboard :
>>> >> > > > - meta-fsl-arm :
>>> >> > > > * linux-imx_xyz.bb :
>>> >> > > > SRC_URI = "patchgeneric1 ..."
>>> >> > > >
>>> >> > > > - meta-som-support :
>>> >> > > > * conf/machine/mysom.conf
>>> >> > > >
>>> >> > > > * linux-imx_xyz.bbappend :
>>> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>>> >> > > >
>>> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>>> >> > > > * conf/machine/myproduct.conf
>>> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
>>> >> > > > include conf/machine/mysom.conf
>>> >> > > >
>>> >> > > > * linux-imx_xyz.bbappend :
>>> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>>> >> > > >
>>> >> > > > in the end I get :
>>> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>>> >> > > > patchsom1 ..."
>>> >> > > >
>>> >> > > > and of course as patchproduct* are supposed to apply on top of
>>> >> > > > patchsoc* the patch fail to apply.
>>> >> > > >
>>> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
>>> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
>>> >> > > > changing machine's name to see if that was an alphabetical order ...).
>>> >> > > >
>>> >> > > > In the end the only thing which worked was to add an (empty by default)
>>> >> > > > variable in som's SRC_URI and filling this variables from the
>>> >> > > > custommotherboard's bbappend.
>>> >> > > >
>>> >> > > > Is the behaviour I'm seeing expected or is there something wrong in my
>>> >> > > > setup ?
>>> >> > >
>>> >> > > what is your OVERRIDES order.
>>> >> > >
>>> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>>> >> >
>>> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>>> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>>> >>
>>> >> I think what Khem is asking is what OVERRIDES expands to?
>>> >>
>>> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>>> >> patchsoc2?
>>> >>
>>> > oops :
>>> > I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
>>> > and I get :
>>> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>>> >
>>> >> Its hard to follow and it might be easier if you could share a
>>> >> simplified test case we could reproduce this with. I don't doubt there
>>> >> is an issue in there but we need a way to reproduce and debug this.
>>> >>
>>> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
>>> > meta-fsl-arm + meta-som + meta-baseboard.
>>> >
>>> > Eric
>>> > _______________________________________________
>>> > Openembedded-core mailing list
>>> > Openembedded-core@lists.openembedded.org
>>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>> I have to report an undesiderate behavior:
>>>
>>> the formfactor files in our .bbappend are not considered :/
>>> DEBUG: Searching for machconfig in paths:....
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>>>
>>> so we end up with the empty machconfig of
>>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>>
>>> Surely this didn't happen when we tested the recipe.
>>
>> With which revision of OE-Core? Was this with the dora release tag,
>> current dora head or master?
>>
>> Cheers,
>>
>> Richard
>>
>>
>
> This was with fresh master:
>
> Build Configuration:
> BB_VERSION        = "1.21.0"
> BUILD_SYS         = "i686-linux"
> NATIVELSBSTRING   = "Gentoo"
> TARGET_SYS        = "arm-oe-linux-gnueabi"
> MACHINE           = "poodle"
> DISTRO_VERSION    = "oe-core.0"
> TUNE_FEATURES     = "armv5 thumb dsp"
> TARGET_FPU        = "soft"
> meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
> meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
> meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
>
> Cheers
FYI
In the hurry for a solution for fixing formfactor and ipaq-boot-params
my quick hack was to revert

http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552

That appears to fix the specific issue...

Andrea

Re: [OE-core] SRC_URI computing order

[Andrea Adami]

On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>>> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard <eric@eukrea.com> wrote:
>>> > Hi Richard,
>>> >
>>> > Le Wed, 30 Oct 2013 15:15:12 +0000,
>>> > Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :
>>> >
>>> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>>> >> > Hi Khem,
>>> >> >
>>> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>>> >> > Khem Raj <raj.khem@gmail.com> a écrit :
>>> >> >
>>> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard <eric@eukrea.com> wrote:
>>> >> > > > Hi Richard,
>>> >> > > >
>>> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>>> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>>> >> > > > problem when SRC_URI is computed.
>>> >> > > >
>>> >> > > > So when building SRC_URI when two layers have bbappend which apply
>>> >> > > > patches : the SRC_URI seems to be built using an order I fail to
>>> >> > > > understand somewhere instead of priority or the overrides' order.
>>> >> > > >
>>> >> > > > The use case is a System on Module and its custom motherboard :
>>> >> > > > - meta-fsl-arm :
>>> >> > > > * linux-imx_xyz.bb :
>>> >> > > > SRC_URI = "patchgeneric1 ..."
>>> >> > > >
>>> >> > > > - meta-som-support :
>>> >> > > > * conf/machine/mysom.conf
>>> >> > > >
>>> >> > > > * linux-imx_xyz.bbappend :
>>> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>>> >> > > >
>>> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>>> >> > > > * conf/machine/myproduct.conf
>>> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
>>> >> > > > include conf/machine/mysom.conf
>>> >> > > >
>>> >> > > > * linux-imx_xyz.bbappend :
>>> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>>> >> > > >
>>> >> > > > in the end I get :
>>> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>>> >> > > > patchsom1 ..."
>>> >> > > >
>>> >> > > > and of course as patchproduct* are supposed to apply on top of
>>> >> > > > patchsoc* the patch fail to apply.
>>> >> > > >
>>> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
>>> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
>>> >> > > > changing machine's name to see if that was an alphabetical order ...).
>>> >> > > >
>>> >> > > > In the end the only thing which worked was to add an (empty by default)
>>> >> > > > variable in som's SRC_URI and filling this variables from the
>>> >> > > > custommotherboard's bbappend.
>>> >> > > >
>>> >> > > > Is the behaviour I'm seeing expected or is there something wrong in my
>>> >> > > > setup ?
>>> >> > >
>>> >> > > what is your OVERRIDES order.
>>> >> > >
>>> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>>> >> >
>>> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>>> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>>> >>
>>> >> I think what Khem is asking is what OVERRIDES expands to?
>>> >>
>>> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>>> >> patchsoc2?
>>> >>
>>> > oops :
>>> > I expect  SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
>>> > and I get :
>>> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>>> >
>>> >> Its hard to follow and it might be easier if you could share a
>>> >> simplified test case we could reproduce this with. I don't doubt there
>>> >> is an issue in there but we need a way to reproduce and debug this.
>>> >>
>>> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
>>> > meta-fsl-arm + meta-som + meta-baseboard.
>>> >
>>> > Eric
>>> > _______________________________________________
>>> > Openembedded-core mailing list
>>> > Openembedded-core@lists.openembedded.org
>>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>> I have to report an undesiderate behavior:
>>>
>>> the formfactor files in our .bbappend are not considered :/
>>> DEBUG: Searching for machconfig in paths:....
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>>>
>>> so we end up with the empty machconfig of
>>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>>
>>> Surely this didn't happen when we tested the recipe.
>>
>> With which revision of OE-Core? Was this with the dora release tag,
>> current dora head or master?
>>
>> Cheers,
>>
>> Richard
>>
>>
>
> This was with fresh master:
>
> Build Configuration:
> BB_VERSION        = "1.21.0"
> BUILD_SYS         = "i686-linux"
> NATIVELSBSTRING   = "Gentoo"
> TARGET_SYS        = "arm-oe-linux-gnueabi"
> MACHINE           = "poodle"
> DISTRO_VERSION    = "oe-core.0"
> TUNE_FEATURES     = "armv5 thumb dsp"
> TARGET_FPU        = "soft"
> meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
> meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
> meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
>
> Cheers
FYI
In the hurry for a solution for fixing formfactor and ipaq-boot-params
my quick hack was to revert

http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552

That appears to fix the specific issue...

Andrea

Re: SRC_URI computing order

[Richard Purdie]

On Wed, 2013-11-06 at 09:45 +0100, Andrea Adami wrote:
> On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> > On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
> >>> I have to report an undesiderate behavior:
> >>>
> >>> the formfactor files in our .bbappend are not considered :/
> >>> DEBUG: Searching for machconfig in paths:....
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
> >>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
> >>>
> >>> so we end up with the empty machconfig of
> >>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
> >>>
> >>> Surely this didn't happen when we tested the recipe.
> >>
> >> With which revision of OE-Core? Was this with the dora release tag,
> >> current dora head or master?
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >
> > This was with fresh master:
> >
> > Build Configuration:
> > BB_VERSION        = "1.21.0"
> > BUILD_SYS         = "i686-linux"
> > NATIVELSBSTRING   = "Gentoo"
> > TARGET_SYS        = "arm-oe-linux-gnueabi"
> > MACHINE           = "poodle"
> > DISTRO_VERSION    = "oe-core.0"
> > TUNE_FEATURES     = "armv5 thumb dsp"
> > TARGET_FPU        = "soft"
> > meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
> > meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
> > meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
> >
> > Cheers
> FYI
> In the hurry for a solution for fixing formfactor and ipaq-boot-params
> my quick hack was to revert
> 
> http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552
> 
> That appears to fix the specific issue...

Its a hacky workaround. The real issue is that you don't set DISTRO and
this puts a :: into FILESOVERRIDES (and OVERRIDES). I've sent a patch
out which sets a default for DISTRO since its the nicer way I could find
to fix this. The behaviour in the above patch is correct.

Cheers,

Richard

Re: [OE-core] SRC_URI computing order

[Richard Purdie]

On Wed, 2013-11-06 at 09:45 +0100, Andrea Adami wrote:
> On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> > On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
> >>> I have to report an undesiderate behavior:
> >>>
> >>> the formfactor files in our .bbappend are not considered :/
> >>> DEBUG: Searching for machconfig in paths:....
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
> >>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
> >>>
> >>> so we end up with the empty machconfig of
> >>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
> >>>
> >>> Surely this didn't happen when we tested the recipe.
> >>
> >> With which revision of OE-Core? Was this with the dora release tag,
> >> current dora head or master?
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >
> > This was with fresh master:
> >
> > Build Configuration:
> > BB_VERSION        = "1.21.0"
> > BUILD_SYS         = "i686-linux"
> > NATIVELSBSTRING   = "Gentoo"
> > TARGET_SYS        = "arm-oe-linux-gnueabi"
> > MACHINE           = "poodle"
> > DISTRO_VERSION    = "oe-core.0"
> > TUNE_FEATURES     = "armv5 thumb dsp"
> > TARGET_FPU        = "soft"
> > meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
> > meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
> > meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
> >
> > Cheers
> FYI
> In the hurry for a solution for fixing formfactor and ipaq-boot-params
> my quick hack was to revert
> 
> http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552
> 
> That appears to fix the specific issue...

Its a hacky workaround. The real issue is that you don't set DISTRO and
this puts a :: into FILESOVERRIDES (and OVERRIDES). I've sent a patch
out which sets a default for DISTRO since its the nicer way I could find
to fix this. The behaviour in the above patch is correct.

Cheers,

Richard

Re: SRC_URI computing order

[Otavio Salvador]

On Thu, Nov 7, 2013 at 9:20 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-11-06 at 09:45 +0100, Andrea Adami wrote:
>> On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> > On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
>> > <richard.purdie@linuxfoundation.org> wrote:
>> >> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>> >>> I have to report an undesiderate behavior:
>> >>>
>> >>> the formfactor files in our .bbappend are not considered :/
>> >>> DEBUG: Searching for machconfig in paths:....
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>> >>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>> >>>
>> >>> so we end up with the empty machconfig of
>> >>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>> >>>
>> >>> Surely this didn't happen when we tested the recipe.
>> >>
>> >> With which revision of OE-Core? Was this with the dora release tag,
>> >> current dora head or master?
>> >>
>> >> Cheers,
>> >>
>> >> Richard
>> >>
>> >>
>> >
>> > This was with fresh master:
>> >
>> > Build Configuration:
>> > BB_VERSION        = "1.21.0"
>> > BUILD_SYS         = "i686-linux"
>> > NATIVELSBSTRING   = "Gentoo"
>> > TARGET_SYS        = "arm-oe-linux-gnueabi"
>> > MACHINE           = "poodle"
>> > DISTRO_VERSION    = "oe-core.0"
>> > TUNE_FEATURES     = "armv5 thumb dsp"
>> > TARGET_FPU        = "soft"
>> > meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
>> > meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
>> > meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
>> >
>> > Cheers
>> FYI
>> In the hurry for a solution for fixing formfactor and ipaq-boot-params
>> my quick hack was to revert
>>
>> http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552
>>
>> That appears to fix the specific issue...
>
> Its a hacky workaround. The real issue is that you don't set DISTRO and
> this puts a :: into FILESOVERRIDES (and OVERRIDES). I've sent a patch
> out which sets a default for DISTRO since its the nicer way I could find
> to fix this. The behaviour in the above patch is correct.

Can you point this patch?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] SRC_URI computing order

[Otavio Salvador]

On Thu, Nov 7, 2013 at 9:20 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-11-06 at 09:45 +0100, Andrea Adami wrote:
>> On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> > On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
>> > <richard.purdie@linuxfoundation.org> wrote:
>> >> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>> >>> I have to report an undesiderate behavior:
>> >>>
>> >>> the formfactor files in our .bbappend are not considered :/
>> >>> DEBUG: Searching for machconfig in paths:....
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>> >>>   /oe/oe-core/meta/recipes-bsp/formfactor/files/
>> >>>   /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>> >>>
>> >>> so we end up with the empty machconfig of
>> >>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>> >>>
>> >>> Surely this didn't happen when we tested the recipe.
>> >>
>> >> With which revision of OE-Core? Was this with the dora release tag,
>> >> current dora head or master?
>> >>
>> >> Cheers,
>> >>
>> >> Richard
>> >>
>> >>
>> >
>> > This was with fresh master:
>> >
>> > Build Configuration:
>> > BB_VERSION        = "1.21.0"
>> > BUILD_SYS         = "i686-linux"
>> > NATIVELSBSTRING   = "Gentoo"
>> > TARGET_SYS        = "arm-oe-linux-gnueabi"
>> > MACHINE           = "poodle"
>> > DISTRO_VERSION    = "oe-core.0"
>> > TUNE_FEATURES     = "armv5 thumb dsp"
>> > TARGET_FPU        = "soft"
>> > meta              = "master:511b4194165ed7a5645169e09c27db280d5a5316"
>> > meta-initramfs    = "master:4d62e7f575e2a87197c74ab4639561b45eec0e60"
>> > meta-handheld     = "master:55a310666b543e6beca47fa3c197492d5a6cf8ff"
>> >
>> > Cheers
>> FYI
>> In the hurry for a solution for fixing formfactor and ipaq-boot-params
>> my quick hack was to revert
>>
>> http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552
>>
>> That appears to fix the specific issue...
>
> Its a hacky workaround. The real issue is that you don't set DISTRO and
> this puts a :: into FILESOVERRIDES (and OVERRIDES). I've sent a patch
> out which sets a default for DISTRO since its the nicer way I could find
> to fix this. The behaviour in the above patch is correct.

Can you point this patch?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750