[OE-core] [PATCH v2 5/8] siteinfo: Move the rp-pppoe entry to common-linux

[Tom Rini]

On 07/25/2011 09:40 AM, Phil Blundell wrote:
> On Mon, 2011-07-25 at 09:00 -0700, Tom Rini wrote:
>> On 07/25/2011 08:57 AM, Phil Blundell wrote:
>>> On Fri, 2011-07-22 at 10:10 -0700, Tom Rini wrote:
>>>> --- a/meta/site/common-linux
>>>> +++ b/meta/site/common-linux
>>>> @@ -23,3 +23,6 @@ bash_cv_unusable_rtsigs=${bash_cv_unusable_rtsigs=no}
>>>>  # mysql
>>>>  ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls=yes}
>>>>  ac_cv_conv_longlong_to_float=${ac_cv_conv_longlong_to_float=yes}
>>>> +
>>>> +# rp-pppoe
>>>> +rpppoe_cv_pack_bitfields=${rpppoe_cv_pack_bitfields=rev}
>>>
>>> Is that really correct?  Bitfield packing isn't an OS issue, it's
>>> primarily a question of compiler choice.  For GCC I think it correlates
>>> with endianness; looking at what that test is doing, I'd expect you to
>>> get "reversed" on little-endian and "normal" on big-endian.
>>
>> It's possible we're getting this, and have been getting this wrong on
>> big-endian targets but I haven't heard from Freescale this is failing
>> for them.  I'm OK with dropping this bit out for now until we can
>> confirm this test on a BE machine.
> 
> That's probably best.  In any case, as far as I can tell rp-pppoe is
> (despite what you might expect from the name) not actually in oe-core
> itself, so perhaps its definitions don't belong in oe-core's site files
> either.

Yeah.  At one point I was going to try and move the bits that oe-core
doesn't use to meta-oe where they are or likely will be, but possibly
after consolidation (and then just not adding in brand new ones, eg
postgresql).

-- 
Tom Rini
Mentor Graphics Corporation