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