On Thu, Jun 10, 2010 at 03:56:30PM -0700, Khem Raj wrote: >On Thu, Jun 10, 2010 at 1:27 PM, Chris Larson <[email protected]> wrote: >> On Thu, Jun 10, 2010 at 1:22 PM, Phil Blundell <[email protected]> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
