[OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Khem Raj]

On Mon, Apr 9, 2012 at 1:25 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
>
> In order to reconcile the above, the three primary options are see are:
>
> *) Define only mips or mips32 tune, but not both -- producing "mips" as the
> package arch.  (But then what do we do in the future about mips1, mips2,
> mips3, mips4, mips32r2?)
>
> *) Revert the behavior and have two tunes that produce the identical
> filename package with different contents and deal with this in the future.
>
> *) Keep it as it is now and produce mips and mips32 packages based on the
> specific tunings defined by the user

I think situation is not something I like but

I would think that 1st option is better. Any machine that has been using
mips32 tuning accidently could now use mips tune files and get same PKG_ARCH
and we move mips32 tune into mips tune and hereon say that mips 32bit in OE
defaults to -march=mips32

we could also change compiler defaults to use -march=mips32 to match
the baseconfig and since qemumips has been using mips32 anyway that sort
of is base mips arch.

>
> We have a bug, I believe we need to fix it.. first or third options "fix"
> the bug.. the second option retains the bug to be fixed in the future.
>
> If you have an alternative to the above, I'm interested -- I just really
> don't like the "leave the bug" option.
>
> And just to be extra clear, I consider it a defect if we can produce a
> package with the same name for two different tune settings.. (the exception
> being the hell that is ARM and thumb namings.)