On Mon, Apr 9, 2012 at 1:25 PM, Mark Hatle <mark.ha...@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.) _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
