Re: [PATCH 2/2] busybox: configure according to {MACHINE, DISTRO}_FEATURES

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Thu, Jun 10, 2010 at 03:56:30PM -0700, Khem Raj wrote:
>On Thu, Jun 10, 2010 at 1:27 PM, Chris Larson <clarson@kergoth.com> wrote:
>> On Thu, Jun 10, 2010 at 1:22 PM, Phil Blundell <philb@gnu.org> wrote:
>>
>>> On Thu, 2010-06-10 at 12:55 -0700, Chris Larson wrote:
>>> > Should this (ipv6 at least) use COMBINED_FEATURES, since it requires
>>> > kernel/machine support for it to be useful, along with distro support?
>>>
>>> I don't think it's machine dependent in any meaningful way; there is, to
>>> my knowledge, no OE-supported hardware which is actually incapable of
>>> supporting ipv6.  Any distro that wants to use it just needs to make
>>> sure that the kernel support is present (either built-in or as a module)
>>> on all the supported targets.  In any case, most packages will cope
>>> gracefully with ipv6 being selected on in the configuration and then
>>> found to be absent at runtime.
>>>
>>> If you start factoring MACHINE_FEATURES into that kind of decision then,
>>> logically, the package needs to have PACKAGE_ARCH=${MACHINE}.  I don't
>>> think it would be a very good thing to start forcing packages down that
>>> path unnecessarily.
>>
>>
>> Fair enough, that seems reasonable for this particular case.  Now that you
>> bring it up, we adjust package arch to machine when we use a machine
>> specific file:// file, but maybe we need to teach it to check for references
>> to MACHINE_FEATURES or COMBINED_FEATURES, somehow.
>
>will it force recompile then if I choose a similar arch but different
>machine say (qemuarm, osk5912 both are armv5te)

No, unless you end up with
- different tune-*.inc
- mmu/nommu or floatingpoint support