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

[Bernhard Reutner-Fischer]

On Fri, Jun 11, 2010 at 01:59:12PM +0100, Phil Blundell wrote:
>On Thu, 2010-06-10 at 23:20 +0200, Bernhard Reutner-Fischer wrote:
>> If the machine does not provide a choice to use or not use the MMU then
>> it makes no sense to take that into account for the package arch (think
>> bfin or i586 or certain coldfires/m68k), yes. If, OTOH, a machine
>> supports it (let's say ppc) then there must at least be a nice way to
>> distinguish ppc<endian><mmu><floatingpoint> i would have hoped.
>
>Endianness and FPU are clearly both part of the general ABI: virtually
>every package which contains compiled code is going to have a dependency
>on those two settings.  So, for DISTROs which support multiple values
>for either of those options, I would expect them to simply be encoded
>into the default PACKAGE_ARCH (either directly or via TARGET_ARCH); this
>is indeed what's already done with bi-endian ARM for example.  For
>DISTROs which only support one or the other, there's no need to draw the
>distinction.

ok, i see.
>
>MMU is perhaps a little more complicated since, at least in theory, one
>could imagine a DISTRO which supported both MMU-equipped and non-MMU
>hardware and where the majority of binaries were capable of running on
>both targets.  So in that case there might be a legitimate argument for
>making it be a per-package setting in order to get parallel builds of
>those packages that do actually care.  But I think the time to worry
>about that would be when the situation does actually arise in practice.

fair enough

I hereby mass-ping the patches in this thread:
[PATCH 1/3] uClibc: redo configuration
{1/2 was already applied by khem, thanks!}
[PATCH 3/3] busybox: picking IPv6 per default is not up to the package
[PATCH 1/2] uclibc: handle DISTRO_FEATURE="largefile"
[PATCH 2/2] busybox: configure according to {MACHINE,DISTRO}_FEATURES