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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>>>> --- >>>>>>>> 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. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
