[OE-core] MIPS vs MIPS32 tunings -- summary and questions

[Richard Purdie]

On Wed, 2012-04-18 at 14:08 +0200, Andreas Oberritter wrote:
> On 18.04.2012 14:00, Richard Purdie wrote:
> > On Wed, 2012-04-18 at 13:54 +0200, Martin Jansa wrote:
> >> I had a lot of those (e.g. because armv7a-vfp-neon was including 20
> >> arm*feed.conf variants in /etc/opkg most of them empty - without
> >> Packages.gz).
> >>
> >> So I've added "filter" to distro-feed-configs
> >> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
> >> to add only feeds I'm generating (and I also don't want armv5* packages
> >> installed on armv7a-vfp-neon target unless user explicitly adds armv5*
> >> feed).
> > 
> > This is the better solution. I think we need to get a better default
> > feed-config generation mechanism into the core. Distros may still need
> > to tweak it but it would be good to share some of the best practises...
> 
> Did you look at the patch? Which default setting of
> SUPPORTED_EXTRA_ARCHS do you suggest?

I did. I didn't say the above patch was a perfect solution.

>  Do you think it's feasible to add
> every single downloadable arch to this variable? If a user of my distro
> decides to build it for some arm or x86 cpu, should he need to know
> which archs to add at this place?

This is a place where the build system meets and interfaces with the
distro. No one policy in the build system is going to fit every distro's
needs, not should we ever aim to so. I think my comment above shows what
I think is the correct intention, we should aim to find common ground
and share solutions where possible.

You could simply decide your distro only supports PACKAGE_ARCH for a
given target, you could also decide to filter through the list
PACKAGE_ARCHs and remove certain values based on a whitelist or
blacklist. Its a policy decision and one the distro needs to decide on
ultimately.

> I don't think that's user-friendly and I don't know what's so bad about
> removing something that probably hasn't helped anybody.

I disagree. I am sorry you're feeling some pain on this particular
topic, that wasn't intended and I'm hoping we can get that resolved and
move forward quickly.

Cheers,

Richard