On Tue, Dec 15, 2015 at 12:43 PM, Khem Raj <[email protected]> wrote: > >> On Dec 15, 2015, at 12:16 PM, Paul Eggleton <[email protected]> >> wrote: >> >> On Tue, 15 Dec 2015 12:07:48 Andre McCurdy wrote: >>> On Tue, Dec 15, 2015 at 9:26 AM, Paul Eggleton >>> >>> <[email protected]> wrote: >>>> On Tue, 15 Dec 2015 17:28:59 Alexander Kanavin wrote: >>>>> On 12/15/2015 05:25 PM, Martin Jansa wrote: >>>>>>> +COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux' >>>>>>> +COMPATIBLE_HOST_armv7a = 'arm.*-linux' >>>>>> >>>>>> Can you add armv7ve as well? >>>>> >>>>> Armv7ve support is not yet in master, so you'll have to add it later I'm >>>>> afraid. >>>> >>>> I think by policy we don't have any restrictions on architecture-specific >>>> flags in OE-Core (at least, assuming they're reasonable). >>> >>> If we're going to duplicate all _armv7a over-rides for _armv7ve then >>> I'd vote to do so in a single patch series which fixes up the whole of >>> oe-core rather than adding the over-rides one at a time amongst >>> version updates etc. >> >> Makes sense, but before doing that would it make sense to have a grouping >> override for all of them that can be used instead (where appropriate)? >> > > stepping back a step. What so different about armv7ve that it needs to be a > separate arch > its just virtual extensions on top of armv7a, so any override pertaining to > armv7a should > be valid for it well. Can you work towards making it so ?
Trying to create a common over-ride for both might end up causing more trouble in the long run. Perhaps it would instead make sense just to try to remove some the _armv7a over-rides currently used in oe-core (and meta-oe)? There aren't that many and some of them look a little dubious or at least out of date and in need of a review. For example for valgrind, we could blacklist armv4, armv5 and armv6 rather than whitelisting armv7a. The pixman recipe is assuming armv7a is a reliable way to determine NEON support, which it isn't. The libav recipes are using _armv7a to force some dubious looking optimisations. Forcing the bfd linker in DirectFB doesn't need to be architecture specific, etc. The only genuinely valid looking usage of the armv7a over-ride seems to be gcc-configure-common. >> Cheers, >> Paul >> >> -- >> >> Paul Eggleton >> Intel Open Source Technology Centre >> -- >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
