[OE-core] [PATCH v2] valgrind: Enable valgrind for armv7

[Khem Raj]

On Wed, May 30, 2012 at 7:18 AM, Samuel Stirtzel
<s.stirtzel at googlemail.com> wrote:
> 2012/5/30 Khem Raj <raj.khem at gmail.com>:
>>
>>
>> On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>>
>>> 2012/5/30 Khem Raj <raj.khem at gmail.com>:
>>> >
>>> >
>>> > On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>> >>
>>> >> 2012/5/29 Khem Raj <raj.khem at gmail.com>:
>>> >> >>
>>> >> >> At some extend yes, the configuration checks the host, the default
>>> >> >> string passed is "arm" but the configure.in checks for:
>>> >> >>
>>> >> >> case "${host_cpu}" in
>>> >> >> ...
>>> >> >>      armv7*)
>>> >> >>       AC_MSG_RESULT([ok (${host_cpu})])
>>> >> >>       ARCH_MAX="arm"
>>> >> >>
>>> >> >
>>> >> > in OE we know that compiler is configured to generate code for armv7
>
> What does this exactly mean, are non armv7 arches also running armv7 code?
>
>>> >> > therefore you can safely change armv7* above in configure.in to be
>>> >> > arm*
>>> >> >
>>> >>
>>> >> On this change I don't have a strong opinion (looks rather
>>> >> cosmetically).
>>> >> But sure I can send a follow up patch like you suggested.
>>> >
>>> >
>>> > It is not cosmetic if you see it also enables it for non armv7 archs
>>>
>>> Maybe it is a misunderstanding?
>>> Do you also want me to change:
>>>
>>> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
>>> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>>
>>> to: COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64||arm).*-linux'
>>>
>>> Else it would be only a cosmetic change, because the recipe is
>>> preventing non armv7 arch.
>>> Or am I mistaken?
>>>
>>
>> Recipe and package itself are two different things I was commenting on
>> package itself how it's baked in OE is a different thing
>
> You want to pass configure for non armv7 arches but keep baking for
> them disabled?
> Sorry I don't get your point, if the machine is not armv7 compatible
> then it is not compatible with valgrind.
> If they are compatible there is no point in disallowing them to bake the recipe.
>
> Yes it is a difference to enable them at recipe / package level, but
> the effective use of this recipe / package restriction combination
> does not appear useful (to me).
> I think I just miss your point.

Its fine. Dont worry