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. 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. p. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
