[PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

PACKAGE_ARCH is set to BASE_PACKAGE_ARCH so we do not
need to define it here since we already define BASE_PACKAGE_ARCH

angstrom sets FEED_ARCH like

FEED_ARCH ?= "${BASE_PACKAGE_ARCH}"

and 'all' doesnt go well for FEED_ARCH as it ends up with
parsing error for x86 machines.

This might be a latent bug in bitbake but allarch.bbclass
excavated it and we burry it in the same class.

This makes the behavior same as it was before allarch.bbclass
where we set PACKAGE_ARCH = all for common packages

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/classes/allarch.bbclass |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index e3ac392..b9ba28b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -2,9 +2,10 @@
 # This class is used for architecture independent recipes/data files (usally scripts)
 #
 
+# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
+# before we reset it
+FEED_ARCH := ${BASE_PACKAGE_ARCH}
 BASE_PACKAGE_ARCH = "all"
-PACKAGE_ARCH = "all"
-
 # No need for virtual/libc or a cross compiler
 INHIBIT_DEFAULT_DEPS = "1"
 
-- 
1.7.4.1

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 14 jun 2011, om 23:13 heeft Khem Raj het volgende geschreven:

> PACKAGE_ARCH is set to BASE_PACKAGE_ARCH so we do not
> need to define it here since we already define BASE_PACKAGE_ARCH
> 
> angstrom sets FEED_ARCH like
> 
> FEED_ARCH ?= "${BASE_PACKAGE_ARCH}"
> 
> and 'all' doesnt go well for FEED_ARCH as it ends up with
> parsing error for x86 machines.
> 
> This might be a latent bug in bitbake but allarch.bbclass
> excavated it and we burry it in the same class.
> 
> This makes the behavior same as it was before allarch.bbclass
> where we set PACKAGE_ARCH = all for common packages
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>

Just to repeat the questions you answered on IRC already:

this will still result in a foo_1.0_all.ipk, right? So I don't have to recreated the feeds *again* as I needed to do after the machine-name->machine_name changes?

regards,

Koen

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>  meta/classes/allarch.bbclass |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> index e3ac392..b9ba28b 100644
> --- a/meta/classes/allarch.bbclass
> +++ b/meta/classes/allarch.bbclass
> @@ -2,9 +2,10 @@
>  # This class is used for architecture independent recipes/data files (usally scripts)
>  #
>  
> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
> +# before we reset it
> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>  BASE_PACKAGE_ARCH = "all"
> -PACKAGE_ARCH = "all"
> -
>  # No need for virtual/libc or a cross compiler
>  INHIBIT_DEFAULT_DEPS = "1"

This is a *really* bad idea. An "all" package should have no need to set
architecture specific values into FEED_ARCH.

Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
classes like rm_work with "_all" in the function names.
 
I'd suggest that various machines should start adding things like armv7a
to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
that FEED_ARCH should quietly die ;-).

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

On Tue, Jun 14, 2011 at 2:24 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>>  meta/classes/allarch.bbclass |    5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>> index e3ac392..b9ba28b 100644
>> --- a/meta/classes/allarch.bbclass
>> +++ b/meta/classes/allarch.bbclass
>> @@ -2,9 +2,10 @@
>>  # This class is used for architecture independent recipes/data files (usally scripts)
>>  #
>>
>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>> +# before we reset it
>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>  BASE_PACKAGE_ARCH = "all"
>> -PACKAGE_ARCH = "all"
>> -
>>  # No need for virtual/libc or a cross compiler
>>  INHIBIT_DEFAULT_DEPS = "1"
>
> This is a *really* bad idea. An "all" package should have no need to set
> architecture specific values into FEED_ARCH.
>
> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> classes like rm_work with "_all" in the function names.
>
> I'd suggest that various machines should start adding things like armv7a
> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
> that FEED_ARCH should quietly die ;-).

Would it make sense to add TARGET_SUBARCH variable ?

TARRGET_ARCH = arm
TARGET_SUBARCH = armv7a
MACHINE=beagleboard

and in bitbake.conf

TARGET_SUBARCH ??= "${TARGET_ARCH}"

>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 14 jun 2011, om 23:32 heeft Khem Raj het volgende geschreven:

> On Tue, Jun 14, 2011 at 2:24 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>> ---
>>>  meta/classes/allarch.bbclass |    5 +++--
>>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>> index e3ac392..b9ba28b 100644
>>> --- a/meta/classes/allarch.bbclass
>>> +++ b/meta/classes/allarch.bbclass
>>> @@ -2,9 +2,10 @@
>>>  # This class is used for architecture independent recipes/data files (usally scripts)
>>>  #
>>> 
>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>> +# before we reset it
>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>  BASE_PACKAGE_ARCH = "all"
>>> -PACKAGE_ARCH = "all"
>>> -
>>>  # No need for virtual/libc or a cross compiler
>>>  INHIBIT_DEFAULT_DEPS = "1"
>> 
>> This is a *really* bad idea. An "all" package should have no need to set
>> architecture specific values into FEED_ARCH.
>> 
>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>> classes like rm_work with "_all" in the function names.
>> 
>> I'd suggest that various machines should start adding things like armv7a
>> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
>> that FEED_ARCH should quietly die ;-).
> 
> Would it make sense to add TARGET_SUBARCH variable ?

and have it mean the same as BASE_PACKAGE_ARCH?

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

On Tue, Jun 14, 2011 at 2:33 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 14 jun 2011, om 23:32 heeft Khem Raj het volgende geschreven:
>
>> On Tue, Jun 14, 2011 at 2:24 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
>>>>  meta/classes/allarch.bbclass |    5 +++--
>>>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>> index e3ac392..b9ba28b 100644
>>>> --- a/meta/classes/allarch.bbclass
>>>> +++ b/meta/classes/allarch.bbclass
>>>> @@ -2,9 +2,10 @@
>>>>  # This class is used for architecture independent recipes/data files (usally scripts)
>>>>  #
>>>>
>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>> +# before we reset it
>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>>  BASE_PACKAGE_ARCH = "all"
>>>> -PACKAGE_ARCH = "all"
>>>> -
>>>>  # No need for virtual/libc or a cross compiler
>>>>  INHIBIT_DEFAULT_DEPS = "1"
>>>
>>> This is a *really* bad idea. An "all" package should have no need to set
>>> architecture specific values into FEED_ARCH.
>>>
>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>> classes like rm_work with "_all" in the function names.
>>>
>>> I'd suggest that various machines should start adding things like armv7a
>>> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
>>> that FEED_ARCH should quietly die ;-).
>>
>> Would it make sense to add TARGET_SUBARCH variable ?
>
> and have it mean the same as BASE_PACKAGE_ARCH?

May be in some cases, but it wont be associated with packaging

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>> meta/classes/allarch.bbclass |    5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>> 
>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>> index e3ac392..b9ba28b 100644
>> --- a/meta/classes/allarch.bbclass
>> +++ b/meta/classes/allarch.bbclass
>> @@ -2,9 +2,10 @@
>> # This class is used for architecture independent recipes/data files (usally scripts)
>> #
>> 
>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>> +# before we reset it
>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>> BASE_PACKAGE_ARCH = "all"
>> -PACKAGE_ARCH = "all"
>> -
>> # No need for virtual/libc or a cross compiler
>> INHIBIT_DEFAULT_DEPS = "1"
> 
> This is a *really* bad idea. An "all" package should have no need to set
> architecture specific values into FEED_ARCH.
> 
> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> classes like rm_work with "_all" in the function names.

So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?

> I'd suggest that various machines should start adding things like armv7a
> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
> that FEED_ARCH should quietly die ;-).

And that's what I've start calling a 'yocto' type of solution. That just doesn't scale since it relies on fixing all the machines out there instead of levering the knowledge provided by OE already. I'd appreciate a solution is better thought out.

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>
>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>> ---
>>> meta/classes/allarch.bbclass |    5 +++--
>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>> index e3ac392..b9ba28b 100644
>>> --- a/meta/classes/allarch.bbclass
>>> +++ b/meta/classes/allarch.bbclass
>>> @@ -2,9 +2,10 @@
>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>> #
>>>
>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>> +# before we reset it
>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>> BASE_PACKAGE_ARCH = "all"
>>> -PACKAGE_ARCH = "all"
>>> -
>>> # No need for virtual/libc or a cross compiler
>>> INHIBIT_DEFAULT_DEPS = "1"
>>
>> This is a *really* bad idea. An "all" package should have no need to set
>> architecture specific values into FEED_ARCH.
>>
>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>> classes like rm_work with "_all" in the function names.
>
> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
>

because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
tune-xscale.inc

BASE_PACKAGE_ARCH = "${@['armv5teb',
'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"

PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"

and this does not get evaluated properly then

>> I'd suggest that various machines should start adding things like armv7a
>> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
>> that FEED_ARCH should quietly die ;-).
>
> And that's what I've start calling a 'yocto' type of solution. That just doesn't scale since it relies on fixing all the machines out there instead of levering the knowledge provided by OE already. I'd appreciate a solution is better thought out.
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:

> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
>>>> meta/classes/allarch.bbclass |    5 +++--
>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>> index e3ac392..b9ba28b 100644
>>>> --- a/meta/classes/allarch.bbclass
>>>> +++ b/meta/classes/allarch.bbclass
>>>> @@ -2,9 +2,10 @@
>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>> #
>>>> 
>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>> +# before we reset it
>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>> BASE_PACKAGE_ARCH = "all"
>>>> -PACKAGE_ARCH = "all"
>>>> -
>>>> # No need for virtual/libc or a cross compiler
>>>> INHIBIT_DEFAULT_DEPS = "1"
>>> 
>>> This is a *really* bad idea. An "all" package should have no need to set
>>> architecture specific values into FEED_ARCH.
>>> 
>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>> classes like rm_work with "_all" in the function names.
>> 
>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
>> 
> 
> because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
> tune-xscale.inc
> 
> BASE_PACKAGE_ARCH = "${@['armv5teb',
> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> 
> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> 
> and this does not get evaluated properly then

But that wouldn't matter in the scope of allarch, though?

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
>
>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>
>>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>>>
>>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>> ---
>>>>> meta/classes/allarch.bbclass |    5 +++--
>>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>>> index e3ac392..b9ba28b 100644
>>>>> --- a/meta/classes/allarch.bbclass
>>>>> +++ b/meta/classes/allarch.bbclass
>>>>> @@ -2,9 +2,10 @@
>>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>>> #
>>>>>
>>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>>> +# before we reset it
>>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>>> BASE_PACKAGE_ARCH = "all"
>>>>> -PACKAGE_ARCH = "all"
>>>>> -
>>>>> # No need for virtual/libc or a cross compiler
>>>>> INHIBIT_DEFAULT_DEPS = "1"
>>>>
>>>> This is a *really* bad idea. An "all" package should have no need to set
>>>> architecture specific values into FEED_ARCH.
>>>>
>>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>>> classes like rm_work with "_all" in the function names.
>>>
>>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
>>>
>>
>> because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
>> tune-xscale.inc
>>
>> BASE_PACKAGE_ARCH = "${@['armv5teb',
>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>
>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>
>> and this does not get evaluated properly then
>
> But that wouldn't matter in the scope of allarch, though?

SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"

def siteinfo_get_endianess(d):
       info = get_siteinfo_list(d)
       if 'endian-little' in info:
              return "le"
       elif 'endian-big' in info:
              return "be"
       bb.error("Site info could not determine endianess for target")


and
get_siteinfo_list has this

       targetinfo = {\
               "allarch-linux":           "",\

hence siteinfo_get_endianess ends up with

bb.error("Site info could not determine endianess for target")

may be we need to differentiate with None return and empty string
return along with 'endian-little' and 'endian-big'
or may be add another option called 'endian-neutral'

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:

> On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
>> 
>>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>> 
>>>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>>>> 
>>>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>>> ---
>>>>>> meta/classes/allarch.bbclass |    5 +++--
>>>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>> 
>>>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>>>> index e3ac392..b9ba28b 100644
>>>>>> --- a/meta/classes/allarch.bbclass
>>>>>> +++ b/meta/classes/allarch.bbclass
>>>>>> @@ -2,9 +2,10 @@
>>>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>>>> #
>>>>>> 
>>>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>>>> +# before we reset it
>>>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>>>> BASE_PACKAGE_ARCH = "all"
>>>>>> -PACKAGE_ARCH = "all"
>>>>>> -
>>>>>> # No need for virtual/libc or a cross compiler
>>>>>> INHIBIT_DEFAULT_DEPS = "1"
>>>>> 
>>>>> This is a *really* bad idea. An "all" package should have no need to set
>>>>> architecture specific values into FEED_ARCH.
>>>>> 
>>>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>>>> classes like rm_work with "_all" in the function names.
>>>> 
>>>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
>>>> 
>>> 
>>> because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
>>> tune-xscale.inc
>>> 
>>> BASE_PACKAGE_ARCH = "${@['armv5teb',
>>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> 
>>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
>>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> 
>>> and this does not get evaluated properly then
>> 
>> But that wouldn't matter in the scope of allarch, though?
> 
> SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"
> 
> def siteinfo_get_endianess(d):
>       info = get_siteinfo_list(d)
>       if 'endian-little' in info:
>              return "le"
>       elif 'endian-big' in info:
>              return "be"
>       bb.error("Site info could not determine endianess for target")
> 
> 
> and
> get_siteinfo_list has this
> 
>       targetinfo = {\
>               "allarch-linux":           "",\
> 
> hence siteinfo_get_endianess ends up with
> 
> bb.error("Site info could not determine endianess for target")
> 
> may be we need to differentiate with None return and empty string
> return along with 'endian-little' and 'endian-big'
> or may be add another option called 'endian-neutral'

Or just add a bogus endianness: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Wed, 2011-06-15 at 09:00 +0200, Koen Kooi wrote:
> Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:
> 
> > On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> 
> >> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
> >> 
> >>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>>> 
> >>>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
> >>>> 
> >>>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
> >>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >>>>>> ---
> >>>>>> meta/classes/allarch.bbclass |    5 +++--
> >>>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
> >>>>>> 
> >>>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> >>>>>> index e3ac392..b9ba28b 100644
> >>>>>> --- a/meta/classes/allarch.bbclass
> >>>>>> +++ b/meta/classes/allarch.bbclass
> >>>>>> @@ -2,9 +2,10 @@
> >>>>>> # This class is used for architecture independent recipes/data files (usally scripts)
> >>>>>> #
> >>>>>> 
> >>>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
> >>>>>> +# before we reset it
> >>>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
> >>>>>> BASE_PACKAGE_ARCH = "all"
> >>>>>> -PACKAGE_ARCH = "all"
> >>>>>> -
> >>>>>> # No need for virtual/libc or a cross compiler
> >>>>>> INHIBIT_DEFAULT_DEPS = "1"
> >>>>> 
> >>>>> This is a *really* bad idea. An "all" package should have no need to set
> >>>>> architecture specific values into FEED_ARCH.
> >>>>> 
> >>>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> >>>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> >>>>> classes like rm_work with "_all" in the function names.
> >>>> 
> >>>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
> >>>> 
> >>> 
> >>> because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
> >>> tune-xscale.inc
> >>> 
> >>> BASE_PACKAGE_ARCH = "${@['armv5teb',
> >>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> 
> >>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
> >>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> 
> >>> and this does not get evaluated properly then
> >> 
> >> But that wouldn't matter in the scope of allarch, though?
> > 
> > SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"
> > 
> > def siteinfo_get_endianess(d):
> >       info = get_siteinfo_list(d)
> >       if 'endian-little' in info:
> >              return "le"
> >       elif 'endian-big' in info:
> >              return "be"
> >       bb.error("Site info could not determine endianess for target")
> > 
> > 
> > and
> > get_siteinfo_list has this
> > 
> >       targetinfo = {\
> >               "allarch-linux":           "",\
> > 
> > hence siteinfo_get_endianess ends up with
> > 
> > bb.error("Site info could not determine endianess for target")
> > 
> > may be we need to differentiate with None return and empty string
> > return along with 'endian-little' and 'endian-big'
> > or may be add another option called 'endian-neutral'
> 
> Or just add a bogus endianness: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b

This is just papering over cracks. "allarch" packages shouldn't be
querying endianness, it really is that simple.

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 12:16 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-06-15 at 09:00 +0200, Koen Kooi wrote:
>> Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:
>> 
>>> On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>> 
>>>> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
>>>> 
>>>>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>>> 
>>>>>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>>>>>> 
>>>>>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>>>>> ---
>>>>>>>> meta/classes/allarch.bbclass |    5 +++--
>>>>>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>>>> 
>>>>>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>>>>>> index e3ac392..b9ba28b 100644
>>>>>>>> --- a/meta/classes/allarch.bbclass
>>>>>>>> +++ b/meta/classes/allarch.bbclass
>>>>>>>> @@ -2,9 +2,10 @@
>>>>>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>>>>>> #
>>>>>>>> 
>>>>>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>>>>>> +# before we reset it
>>>>>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>>>>>> BASE_PACKAGE_ARCH = "all"
>>>>>>>> -PACKAGE_ARCH = "all"
>>>>>>>> -
>>>>>>>> # No need for virtual/libc or a cross compiler
>>>>>>>> INHIBIT_DEFAULT_DEPS = "1"
>>>>>>> 
>>>>>>> This is a *really* bad idea. An "all" package should have no need to set
>>>>>>> architecture specific values into FEED_ARCH.
>>>>>>> 
>>>>>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>>>>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>>>>>> classes like rm_work with "_all" in the function names.
>>>>>> 
>>>>>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not touch BASE_PACKAGE_ARCH and FEED_ARCH?
>>>>>> 
>>>>> 
>>>>> because there are some machines conf files which use BASE_PACKAGE_ARCH e.g.
>>>>> tune-xscale.inc
>>>>> 
>>>>> BASE_PACKAGE_ARCH = "${@['armv5teb',
>>>>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> 
>>>>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
>>>>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> 
>>>>> and this does not get evaluated properly then
>>>> 
>>>> But that wouldn't matter in the scope of allarch, though?
>>> 
>>> SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"
>>> 
>>> def siteinfo_get_endianess(d):
>>>      info = get_siteinfo_list(d)
>>>      if 'endian-little' in info:
>>>             return "le"
>>>      elif 'endian-big' in info:
>>>             return "be"
>>>      bb.error("Site info could not determine endianess for target")
>>> 
>>> 
>>> and
>>> get_siteinfo_list has this
>>> 
>>>      targetinfo = {\
>>>              "allarch-linux":           "",\
>>> 
>>> hence siteinfo_get_endianess ends up with
>>> 
>>> bb.error("Site info could not determine endianess for target")
>>> 
>>> may be we need to differentiate with None return and empty string
>>> return along with 'endian-little' and 'endian-big'
>>> or may be add another option called 'endian-neutral'
>> 
>> Or just add a bogus endianness: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b
> 
> This is just papering over cracks. "allarch" packages shouldn't be
> querying endianness, it really is that simple.

This isn't the recipes querying the endianness, but the class itself.

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Wed, 2011-06-15 at 12:18 +0200, Koen Kooi wrote:
> Op 15 jun 2011, om 12:16 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-06-15 at 09:00 +0200, Koen Kooi wrote:
> >> Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:
> >> 
> >>> On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>>> 
> >>>> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
> >>>> 
> >>>>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>>>>> 
> >>>>> BASE_PACKAGE_ARCH = "${@['armv5teb',
> >>>>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>>>> 
> >>>>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
> >>>>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>>>> 
> >>>>> and this does not get evaluated properly then
> >>>> 
> >>>> But that wouldn't matter in the scope of allarch, though?
> >>> 
> >>> SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"
> >>> 
> >>> def siteinfo_get_endianess(d):
> >>>      info = get_siteinfo_list(d)
> >>>      if 'endian-little' in info:
> >>>             return "le"
> >>>      elif 'endian-big' in info:
> >>>             return "be"
> >>>      bb.error("Site info could not determine endianess for target")
> >>> 
> >>> 
> >>> and
> >>> get_siteinfo_list has this
> >>> 
> >>>      targetinfo = {\
> >>>              "allarch-linux":           "",\
> >>> 
> >>> hence siteinfo_get_endianess ends up with
> >>> 
> >>> bb.error("Site info could not determine endianess for target")
> >>> 
> >>> may be we need to differentiate with None return and empty string
> >>> return along with 'endian-little' and 'endian-big'
> >>> or may be add another option called 'endian-neutral'
> >> 
> >> Or just add a bogus endianness: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b
> > 
> > This is just papering over cracks. "allarch" packages shouldn't be
> > querying endianness, it really is that simple.
> 
> This isn't the recipes querying the endianness, but the class itself.

Er, if nothing references the appropriate variable, the query is never
made...

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Khem Raj]

On 06/15/2011 03:23 AM, Richard Purdie wrote:
> On Wed, 2011-06-15 at 12:18 +0200, Koen Kooi wrote:
>> Op 15 jun 2011, om 12:16 heeft Richard Purdie het volgende geschreven:
>>
>>> On Wed, 2011-06-15 at 09:00 +0200, Koen Kooi wrote:
>>>> Op 15 jun 2011, om 01:12 heeft Khem Raj het volgende geschreven:
>>>>
>>>>> On Tue, Jun 14, 2011 at 2:44 PM, Koen Kooi<koen@dominion.thruhere.net>  wrote:
>>>>>>
>>>>>> Op 14 jun 2011, om 23:40 heeft Khem Raj het volgende geschreven:
>>>>>>
>>>>>>> On Tue, Jun 14, 2011 at 2:32 PM, Koen Kooi<koen@dominion.thruhere.net>  wrote:
>>>>>>>>
>>>>>>> BASE_PACKAGE_ARCH = "${@['armv5teb',
>>>>>>> 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>>>
>>>>>>> PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4
>>>>>>> armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>>>
>>>>>>> and this does not get evaluated properly then
>>>>>>
>>>>>> But that wouldn't matter in the scope of allarch, though?
>>>>>
>>>>> SITEINFO_ENDIANESS  = "${@siteinfo_get_endianess(d)}"
>>>>>
>>>>> def siteinfo_get_endianess(d):
>>>>>       info = get_siteinfo_list(d)
>>>>>       if 'endian-little' in info:
>>>>>              return "le"
>>>>>       elif 'endian-big' in info:
>>>>>              return "be"
>>>>>       bb.error("Site info could not determine endianess for target")
>>>>>
>>>>>
>>>>> and
>>>>> get_siteinfo_list has this
>>>>>
>>>>>       targetinfo = {\
>>>>>               "allarch-linux":           "",\
>>>>>
>>>>> hence siteinfo_get_endianess ends up with
>>>>>
>>>>> bb.error("Site info could not determine endianess for target")
>>>>>
>>>>> may be we need to differentiate with None return and empty string
>>>>> return along with 'endian-little' and 'endian-big'
>>>>> or may be add another option called 'endian-neutral'
>>>>
>>>> Or just add a bogus endianness: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=f95ffd6cedb2a0fcad9db1b2d612663a327be87b
>>>
>>> This is just papering over cracks. "allarch" packages shouldn't be
>>> querying endianness, it really is that simple.
>>
>> This isn't the recipes querying the endianness, but the class itself.
>
> Er, if nothing references the appropriate variable, the query is never
> made...

certain variables which are common across all kind of recipes e.g. 
IMAGE_NAME could use endian information to have endian information in
image name but they get evaluated in all recipes. so there in lies the 
problem


>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Tue, 2011-06-14 at 23:32 +0200, Koen Kooi wrote:
> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
> 
> > On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >> meta/classes/allarch.bbclass |    5 +++--
> >> 1 files changed, 3 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> >> index e3ac392..b9ba28b 100644
> >> --- a/meta/classes/allarch.bbclass
> >> +++ b/meta/classes/allarch.bbclass
> >> @@ -2,9 +2,10 @@
> >> # This class is used for architecture independent recipes/data files (usally scripts)
> >> #
> >> 
> >> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
> >> +# before we reset it
> >> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
> >> BASE_PACKAGE_ARCH = "all"
> >> -PACKAGE_ARCH = "all"
> >> -
> >> # No need for virtual/libc or a cross compiler
> >> INHIBIT_DEFAULT_DEPS = "1"
> > 
> > This is a *really* bad idea. An "all" package should have no need to set
> > architecture specific values into FEED_ARCH.
> > 
> > Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> > to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> > classes like rm_work with "_all" in the function names.
> 
> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not
> touch BASE_PACKAGE_ARCH and FEED_ARCH?

Because then FEED_ARCH and BASE_PACKAGE_ARCH contain machine specific
data, and the sstate packages become machine specific. When we're trying
to create architecture independent packages, this isn't desirable and
people complained about too much of the system rebuilding...

There is an underlying problem of why BASE_PACKAGE_ARCH and/or FEED_ARCH
is being used but it did seem like one way to fix several of the
problems people were seeing (not realising it would leak into OVERRIDES
too).

> > I'd suggest that various machines should start adding things like armv7a
> > to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
> > that FEED_ARCH should quietly die ;-).
> 
> And that's what I've start calling a 'yocto' type of solution.

Was it really necessary to add that? ;-)

I'm tempted to write some definitions of my own but I'll refrain.

>  That just doesn't scale since it relies on fixing all the machines
> out there instead of levering the knowledge provided by OE already.
> I'd appreciate a solution is better thought out.

Well, I was trying to provide some hints as to how we might be able to
improve this situation, not write the whole roadmap. From what I
remember and the quick discussion we had offlist there are two things
FEED_ARCH tries to do:

a) Provide an addition to overrides that represents the
optimisation/tune profile being used (like armv7a).

b) Provide some info in BASE_PACKAGE_ARCH so that when PACKAGE_ARCH is
overwritten, you can still find out what it would have been set to.

For a), we could update the common include files for the omap/armv7a
platforms and append to MACHINEOVERRIDES there with the appropriate
entries. This would then specifically add a value to OVERRIDES making it
clear that the platform accepted those specific overrides. The variable
has one clear single purpose and intent.

For b), BASE_PACKAGE_ARCH is fine as a variable. Again, we have a
variable with a clear meaning and intent. It would be preferable to use
it rather than FEED_ARCH and phase out the use of FEED_ARCH over time as
that variable does not have a clear meaning or standardised use, its
being used for several different things.

The remaining question is then whether allarch.bbclass should set
BASE_PACKAGE_ARCH. I remain of the opinion that any "allarch" recipe
should not be seeing machine or architecture specific values. It
therefore shouldn't actually make any different whether its set or not,
or what its set to. "all" or "INVALID" are probably the best choices as
they protect people from themselves a little.

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-06-14 at 23:32 +0200, Koen Kooi wrote:
>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>> ---
>>>> meta/classes/allarch.bbclass |    5 +++--
>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>> index e3ac392..b9ba28b 100644
>>>> --- a/meta/classes/allarch.bbclass
>>>> +++ b/meta/classes/allarch.bbclass
>>>> @@ -2,9 +2,10 @@
>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>> #
>>>> 
>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>> +# before we reset it
>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>> BASE_PACKAGE_ARCH = "all"
>>>> -PACKAGE_ARCH = "all"
>>>> -
>>>> # No need for virtual/libc or a cross compiler
>>>> INHIBIT_DEFAULT_DEPS = "1"
>>> 
>>> This is a *really* bad idea. An "all" package should have no need to set
>>> architecture specific values into FEED_ARCH.
>>> 
>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>> classes like rm_work with "_all" in the function names.
>> 
>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not
>> touch BASE_PACKAGE_ARCH and FEED_ARCH?
> 
> Because then FEED_ARCH and BASE_PACKAGE_ARCH contain machine specific
> data, and the sstate packages become machine specific. When we're trying
> to create architecture independent packages, this isn't desirable and
> people complained about too much of the system rebuilding...
> 
> There is an underlying problem of why BASE_PACKAGE_ARCH and/or FEED_ARCH
> is being used but it did seem like one way to fix several of the
> problems people were seeing (not realising it would leak into OVERRIDES
> too).
> 
>>> I'd suggest that various machines should start adding things like armv7a
>>> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
>>> that FEED_ARCH should quietly die ;-).
>> 
>> And that's what I've start calling a 'yocto' type of solution.
> 
> Was it really necessary to add that? ;-)
> 
> I'm tempted to write some definitions of my own but I'll refrain.
> 
>> That just doesn't scale since it relies on fixing all the machines
>> out there instead of levering the knowledge provided by OE already.
>> I'd appreciate a solution is better thought out.
> 
> Well, I was trying to provide some hints as to how we might be able to
> improve this situation, not write the whole roadmap. From what I
> remember and the quick discussion we had offlist there are two things
> FEED_ARCH tries to do:
> 
> a) Provide an addition to overrides that represents the
> optimisation/tune profile being used (like armv7a).
> 
> b) Provide some info in BASE_PACKAGE_ARCH so that when PACKAGE_ARCH is
> overwritten, you can still find out what it would have been set to.
> 
> For a), we could update the common include files for the omap/armv7a
> platforms and append to MACHINEOVERRIDES there with the appropriate
> entries

It's not omap specific, you really need have access to the arch in overrides for *all* platforms. I'm using armv7a is an example since angstrom does TARGET_FPU_armv7a = "hard", but it also does that for various powerpc architectures.

And any change like this would need to get propagated to all the machine layers out there as well, unlike .dev where everything was in one place.

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
> > Well, I was trying to provide some hints as to how we might be able to
> > improve this situation, not write the whole roadmap. From what I
> > remember and the quick discussion we had offlist there are two things
> > FEED_ARCH tries to do:
> > 
> > a) Provide an addition to overrides that represents the
> > optimisation/tune profile being used (like armv7a).
> > 
> > b) Provide some info in BASE_PACKAGE_ARCH so that when PACKAGE_ARCH is
> > overwritten, you can still find out what it would have been set to.
> > 
> > For a), we could update the common include files for the omap/armv7a
> > platforms and append to MACHINEOVERRIDES there with the appropriate
> > entries
> 
> It's not omap specific, you really need have access to the arch in
> overrides for *all* platforms. I'm using armv7a is an example since
> angstrom does TARGET_FPU_armv7a = "hard", but it also does that for
> various powerpc architectures.

I'm also using omap as an example. I'd imagine the powerpc bits would
also work from a common small set of tune include files though? I
suspect the Intel guys would love some way to say "x86" instead of
"i386|i486|i586|i686" etc. so this is a general problem.
> 
> And any change like this would need to get propagated to all the
> machine layers out there as well, unlike .dev where everything was in
> one place.

I know, but we have two choices:

a) Continue this spiral of confusing variable names, conflict and wacky 
   bugs

b) Come up with a plan to address it and roll it out

I'm favouring b), particularly since this would help several different
architectures with a variety of issues. If we need to better document
that and have a process fine, but that is not a good argument for not
doing it at all.

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
>> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
>>> Well, I was trying to provide some hints as to how we might be able to
>>> improve this situation, not write the whole roadmap. From what I
>>> remember and the quick discussion we had offlist there are two things
>>> FEED_ARCH tries to do:
>>> 
>>> a) Provide an addition to overrides that represents the
>>> optimisation/tune profile being used (like armv7a).
>>> 
>>> b) Provide some info in BASE_PACKAGE_ARCH so that when PACKAGE_ARCH is
>>> overwritten, you can still find out what it would have been set to.
>>> 
>>> For a), we could update the common include files for the omap/armv7a
>>> platforms and append to MACHINEOVERRIDES there with the appropriate
>>> entries
>> 
>> It's not omap specific, you really need have access to the arch in
>> overrides for *all* platforms. I'm using armv7a is an example since
>> angstrom does TARGET_FPU_armv7a = "hard", but it also does that for
>> various powerpc architectures.
> 
> I'm also using omap as an example. I'd imagine the powerpc bits would
> also work from a common small set of tune include files though? I
> suspect the Intel guys would love some way to say "x86" instead of
> "i386|i486|i586|i686" etc. so this is a general problem.
>> 
>> And any change like this would need to get propagated to all the
>> machine layers out there as well, unlike .dev where everything was in
>> one place.
> 
> I know, but we have two choices:
> 
> a) Continue this spiral of confusing variable names, conflict and wacky 
>   bugs
> 
> b) Come up with a plan to address it and roll it out
> 
> I'm favouring b), particularly since this would help several different
> architectures with a variety of issues. If we need to better document
> that and have a process fine, but that is not a good argument for not
> doing it at all.

I agree on that, put previous efforts in the yocto universe were rushed through (like the machine-name -> machine_name change I keep going on about), so I have a knee jerk reaction to such things nowadays. For various reasons yocto and later oe-core have not been friendly to distros having package feeds out there. Sometimes the changes made things better, but they were still painfull. It seems to be getting better nowadays, which is good, but everyone still needs to be carefull. Pet peeve: missing PR bumps.

What I need for angstrom is a variable that:For 

1) *never* changes its value
2) holds the base arch (armv7a, ppc603e, etc)
3) Is set in *all* the tune include files
4) must be set to complete parsing when MACHINE is set

I don't care if it's in overrides by default or not since that's easy enough to do in distro configs.

regards,

Koen

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote:
> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
> >> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
> > I know, but we have two choices:
> > 
> > a) Continue this spiral of confusing variable names, conflict and wacky 
> >   bugs
> > 
> > b) Come up with a plan to address it and roll it out
> > 
> > I'm favouring b), particularly since this would help several different
> > architectures with a variety of issues. If we need to better document
> > that and have a process fine, but that is not a good argument for not
> > doing it at all.
> 
> I agree on that, put previous efforts in the yocto universe were
> rushed through (like the machine-name -> machine_name change I keep
> going on about), so I have a knee jerk reaction to such things
> nowadays. For various reasons yocto and later oe-core have not been
> friendly to distros having package feeds out there. Sometimes the
> changes made things better, but they were still painfull. It seems to
> be getting better nowadays, which is good, but everyone still needs to
> be carefull. Pet peeve: missing PR bumps.

Well, I think everyone is trying to improve, trying to do better and
hopefully we are learning from any mistakes made.

> What I need for angstrom is a variable that:For 
> 
> 1) *never* changes its value

As I've mentioned several times, I think it is reasonable to allarch to
clear or otherwise invalidate such a variable. That is a very special
case though and setting it to "all" was perhaps a poor choice of value.

> 2) holds the base arch (armv7a, ppc603e, etc)

Sounds like BASE_PACKAGE_ARCH

> 3) Is set in *all* the tune include files

Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH?

Grepping the tune files in OE-Core we seem to be pretty good about this
right now.

> 4) must be set to complete parsing when MACHINE is set

I suspect this doesn't give as much value as you'd think but I'm
indifferent.

> I don't care if it's in overrides by default or not since that's easy
> enough to do in distro configs.

Is this a decision the machine/tune files should make or the distro
though?

Cheers,

Richard

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 13:36 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote:
>> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
>>>> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
>>> I know, but we have two choices:
>>> 
>>> a) Continue this spiral of confusing variable names, conflict and wacky 
>>>  bugs
>>> 
>>> b) Come up with a plan to address it and roll it out
>>> 
>>> I'm favouring b), particularly since this would help several different
>>> architectures with a variety of issues. If we need to better document
>>> that and have a process fine, but that is not a good argument for not
>>> doing it at all.
>> 
>> I agree on that, put previous efforts in the yocto universe were
>> rushed through (like the machine-name -> machine_name change I keep
>> going on about), so I have a knee jerk reaction to such things
>> nowadays. For various reasons yocto and later oe-core have not been
>> friendly to distros having package feeds out there. Sometimes the
>> changes made things better, but they were still painfull. It seems to
>> be getting better nowadays, which is good, but everyone still needs to
>> be carefull. Pet peeve: missing PR bumps.
> 
> Well, I think everyone is trying to improve, trying to do better and
> hopefully we are learning from any mistakes made.
> 
>> What I need for angstrom is a variable that:For 
>> 
>> 1) *never* changes its value
> 
> As I've mentioned several times, I think it is reasonable to allarch to
> clear or otherwise invalidate such a variable. That is a very special
> case though and setting it to "all" was perhaps a poor choice of value.

>> 2) holds the base arch (armv7a, ppc603e, etc)
> 
> Sounds like BASE_PACKAGE_ARCH
> 
>> 3) Is set in *all* the tune include files
> 
> Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH?

Defaulting to TARGET_ARCH would break 4)

> Grepping the tune files in OE-Core we seem to be pretty good about this
> right now.

In OE-core yes, not sure about the other layers.

>> 4) must be set to complete parsing when MACHINE is set
> 
> I suspect this doesn't give as much value as you'd think but I'm
> indifferent.

It's an early warning system :)

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Mark Hatle]

After reading the discussion, and some investigation I did on my own last week..
 I think there is a more fundamental problem then just a couple of variables
changing names and such.  (Perhaps this was eluded to in a previous conversation
that I missed.. but)

I don't see a -clear- definition of a machine, soc, cpu, etc layed out in
oe-core.  What I mean by this is, we have various tune files, we have a few
machine files.. but how do these all fit together?  I wasn't able to just go in
and say "Ohh these are the paremeters for armv7a", I had to dig around and guess
how things got constructed.

What I've done in the past (commerical product, no OE based) is have a series of
configuration files.  Note, the names below are mine, not OE terms!  Keep this
in mind.  The definitions are arranged in a pseudo-hierarchy that allows each
level to add additional information, until the level of information is properly
determined.

arch <- define basic characteristics about an architecture, such as ARM, Power,
SH, MIPS, etc..

ABI <- define basic characteristics about a specific ABI (multilib), living
inside of an arch.  This defines characteristics for gcc, glibc, and "base"
definitions for CFLAGS, CPU instruction sets, etc.. to produce a minimal
compatible set of binaries.   This SHOULD be enough to build a system..

CPU <- tuning files to enable additional CPU features, optimizations, etc.. the
CPU file is not allowed to change the ABI however.  (For instance, it can't
suddenly enable hard-float on a soft-float multilib.)

BSP (machine) <- final tunings specific to a given machine.


The inclusion order is:

arch can only include the 'all' (no arch)
ABI must include one and only one arch
CPU must include one and only one ABI, or may include another CPU
BSP (machine) must include one or more CPUs (this enables multilibs)

So each BSP (machine) configuration defines what CPU tunings, and thus ABIs are
available on it.  It also defines the default ABI, and may override the CPU
tunings if there is something more precise needed for a given board -- such as a
errata workaround.

While the above has worked for me, I'm sure it would need tailoring in oe-core..
 I'm not advocating changing huge sections of variable namings, just putting in
some sanity to each of these levels....  bringing that into play, we can then
expand to what was mentioned below with package feeds and similar.

The "allarch" is inherited from the special no-arch.  This starts the process of
specifying what packaging is available.

Each ABI specifies a "base" package arch for it's settings and ABI.  This gets
added to "any existing items", i.e. the 'all' arch

Each CPU tune gets more and more specific.  Package feed compatibility is
defined here..  For instance an i686 CPU would include the i586, which could
include i486, which could include i386..  This would result in a feed capability
of i686 being the "preferred", and compatible with i586, i486, i386, all.

The BSP (machine) then would do it's final tunings.  That would define the
machine arch as the highest level, things only setup for that machine.

Anyway, something to consider.  I haven't had the time to really dig into OE and
see if any of this makes sense with what we have -- but it might help resolve
some of these issues, and make it easier to manage the arch, tuning, and related
variables in a single hierarchy so we can see what does and doesn't work -- and
what needs improvement.

--Mark

On 6/15/11 6:52 AM, Koen Kooi wrote:
> 
> Op 15 jun 2011, om 13:36 heeft Richard Purdie het volgende geschreven:
> 
>> On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote:
>>> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:
>>>
>>>> On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
>>>>> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
>>>> I know, but we have two choices:
>>>>
>>>> a) Continue this spiral of confusing variable names, conflict and wacky 
>>>>  bugs
>>>>
>>>> b) Come up with a plan to address it and roll it out
>>>>
>>>> I'm favouring b), particularly since this would help several different
>>>> architectures with a variety of issues. If we need to better document
>>>> that and have a process fine, but that is not a good argument for not
>>>> doing it at all.
>>>
>>> I agree on that, put previous efforts in the yocto universe were
>>> rushed through (like the machine-name -> machine_name change I keep
>>> going on about), so I have a knee jerk reaction to such things
>>> nowadays. For various reasons yocto and later oe-core have not been
>>> friendly to distros having package feeds out there. Sometimes the
>>> changes made things better, but they were still painfull. It seems to
>>> be getting better nowadays, which is good, but everyone still needs to
>>> be carefull. Pet peeve: missing PR bumps.
>>
>> Well, I think everyone is trying to improve, trying to do better and
>> hopefully we are learning from any mistakes made.
>>
>>> What I need for angstrom is a variable that:For 
>>>
>>> 1) *never* changes its value
>>
>> As I've mentioned several times, I think it is reasonable to allarch to
>> clear or otherwise invalidate such a variable. That is a very special
>> case though and setting it to "all" was perhaps a poor choice of value.
> 
>>> 2) holds the base arch (armv7a, ppc603e, etc)
>>
>> Sounds like BASE_PACKAGE_ARCH
>>
>>> 3) Is set in *all* the tune include files
>>
>> Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH?
> 
> Defaulting to TARGET_ARCH would break 4)
> 
>> Grepping the tune files in OE-Core we seem to be pretty good about this
>> right now.
> 
> In OE-core yes, not sure about the other layers.
> 
>>> 4) must be set to complete parsing when MACHINE is set
>>
>> I suspect this doesn't give as much value as you'd think but I'm
>> indifferent.
> 
> It's an early warning system :)
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>> meta/classes/allarch.bbclass |    5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>> 
>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>> index e3ac392..b9ba28b 100644
>> --- a/meta/classes/allarch.bbclass
>> +++ b/meta/classes/allarch.bbclass
>> @@ -2,9 +2,10 @@
>> # This class is used for architecture independent recipes/data files (usally scripts)
>> #
>> 
>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>> +# before we reset it
>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>> BASE_PACKAGE_ARCH = "all"
>> -PACKAGE_ARCH = "all"
>> -
>> # No need for virtual/libc or a cross compiler
>> INHIBIT_DEFAULT_DEPS = "1"
> 
> This is a *really* bad idea. An "all" package should have no need to set
> architecture specific values into FEED_ARCH.
> 
> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> classes like rm_work with "_all" in the function names.

So I did the following in angstrom.inc:

# Add FEED_ARCH and SOC_FAMILY to machine overrides so we get access to e.g. 'armv7a' and 'omap3'
# Hopefully we'll never see a machine or arch with 'all' as substring
MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}:${SOC_FAMILY}"

That makes parsing work for MACHINE=crownbay again, but:

koen@dominion:/OE/tentacle/sources/meta-openembedded$ MACHINE=crownbay bitbake foo
NOTE: Out of date cache found, rebuilding...
NOTE: angstrom DOES NOT support gconf-dbus because gconf-dbus has been merged back into main GConf                                                                                         | ETA:  00:03:09
NOTE: angstrom DOES NOT support gconf-dbus-native because gconf-dbus has been merged back into main GConf
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv library is used##############################                                                                   | ETA:  00:00:44
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv library is used#############################################################                                    | ETA:  00:00:24
Parsing recipes: 100% |####################################################################################################################################################################| Time: 00:01:52
Parsing of 1287 .bb files complete (0 cached, 1287 parsed). 1655 targets, 60 skipped, 0 masked, 0 errors.
Traceback (most recent call last):
  File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
Traceback (most recent call last):
  File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
Traceback (most recent call last):
  File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
Traceback (most recent call last):
  File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
    finalizer()
  File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
    finalizer()
  File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
    finalizer()
  File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
    finalizer()
  File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
    data, version = p.load()
ValueError: could not convert string to int
    data, version = p.load()
ValueError: could not convert string to int
    data, version = p.load()
    data, version = p.load()
ValueError: could not convert string to int
ValueError: could not convert string to int
ERROR: Command execution failed: Traceback (most recent call last):
  File "/OE/tentacle/sources/bitbake/lib/bb/command.py", line 99, in runAsyncCommand
    self.cooker.updateCache()
  File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 937, in updateCache
    if not self.parser.parse_next():
  File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 1247, in parse_next
    self.shutdown()
  File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 1236, in shutdown
    bb.codeparser.parser_cache_savemerge(self.cooker.configuration.data)
  File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 121, in parser_cache_savemerge
    data, version = p.load()
ValueError: could not convert string to int

And the same happens for every machine now. So where did I misconvert an int to string?!?!?

regards,

Koen

Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Richard Purdie]

On Wed, 2011-06-15 at 10:56 +0200, Koen Kooi wrote:
> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
> 
> > On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >> meta/classes/allarch.bbclass |    5 +++--
> >> 1 files changed, 3 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> >> index e3ac392..b9ba28b 100644
> >> --- a/meta/classes/allarch.bbclass
> >> +++ b/meta/classes/allarch.bbclass
> >> @@ -2,9 +2,10 @@
> >> # This class is used for architecture independent recipes/data files (usally scripts)
> >> #
> >> 
> >> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
> >> +# before we reset it
> >> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
> >> BASE_PACKAGE_ARCH = "all"
> >> -PACKAGE_ARCH = "all"
> >> -
> >> # No need for virtual/libc or a cross compiler
> >> INHIBIT_DEFAULT_DEPS = "1"
> > 
> > This is a *really* bad idea. An "all" package should have no need to set
> > architecture specific values into FEED_ARCH.
> > 
> > Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
> > to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
> > classes like rm_work with "_all" in the function names.
> 
> So I did the following in angstrom.inc:
> 
> # Add FEED_ARCH and SOC_FAMILY to machine overrides so we get access to e.g. 'armv7a' and 'omap3'
> # Hopefully we'll never see a machine or arch with 'all' as substring
> MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}:${SOC_FAMILY}"
> 
> That makes parsing work for MACHINE=crownbay again, but:
> 
> koen@dominion:/OE/tentacle/sources/meta-openembedded$ MACHINE=crownbay bitbake foo
> NOTE: Out of date cache found, rebuilding...
> NOTE: angstrom DOES NOT support gconf-dbus because gconf-dbus has been merged back into main GConf                                                                                         | ETA:  00:03:09
> NOTE: angstrom DOES NOT support gconf-dbus-native because gconf-dbus has been merged back into main GConf
> NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv library is used##############################                                                                   | ETA:  00:00:44
> NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv library is used#############################################################                                    | ETA:  00:00:24
> Parsing recipes: 100% |####################################################################################################################################################################| Time: 00:01:52
> Parsing of 1287 .bb files complete (0 cached, 1287 parsed). 1655 targets, 60 skipped, 0 masked, 0 errors.
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 235, in _run_finalizers
>     finalizer()
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
>     res = self._callback(*self._args, **self._kwargs)
>   File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
>     finalizer()
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
>     res = self._callback(*self._args, **self._kwargs)
>   File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
>     finalizer()
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
>     res = self._callback(*self._args, **self._kwargs)
>   File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
>     finalizer()
>   File "/usr/lib/python2.6/multiprocessing/util.py", line 174, in __call__
>     res = self._callback(*self._args, **self._kwargs)
>   File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 91, in parser_cache_save
>     data, version = p.load()
> ValueError: could not convert string to int
>     data, version = p.load()
> ValueError: could not convert string to int
>     data, version = p.load()
>     data, version = p.load()
> ValueError: could not convert string to int
> ValueError: could not convert string to int
> ERROR: Command execution failed: Traceback (most recent call last):
>   File "/OE/tentacle/sources/bitbake/lib/bb/command.py", line 99, in runAsyncCommand
>     self.cooker.updateCache()
>   File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 937, in updateCache
>     if not self.parser.parse_next():
>   File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 1247, in parse_next
>     self.shutdown()
>   File "/OE/tentacle/sources/bitbake/lib/bb/cooker.py", line 1236, in shutdown
>     bb.codeparser.parser_cache_savemerge(self.cooker.configuration.data)
>   File "/OE/tentacle/sources/bitbake/lib/bb/codeparser.py", line 121, in parser_cache_savemerge
>     data, version = p.load()
> ValueError: could not convert string to int
> 
> And the same happens for every machine now. So where did I misconvert an int to string?!?!?

Wiping out the code parser cache would fix this. I also pushed a fix for
it to bitbake master.

Cheers,

Richard