On 7/22/11 1:14 PM, Tom Rini wrote: > On 07/22/2011 11:00 AM, Richard Purdie wrote: >> These changes revolve around the idea of tune features. These are >> represented by >> 'flag' strings that are included in the TUNE_FEATURES variable. >> >> Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] >> entry so >> we can know which flags are available in TUNE_FEATURES and have >> documentation about >> what the flags do. We will add sanity code to error if flags are listed in >> TUNE_FEATURES but are not documented in TUNEVALID. >> >> A given tune configuration will want to define one or more predetermined >> sets of >> _FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>. >> For defined tune configuation, <name> should be added to the AVAILTUNE list >> so that >> we can determine what tune configurations are available. Flags cannot be >> used in this >> case as with TUNEVALID since its useful to be able to build up tune lists >> from other >> TUNE_FEATURES_tune-yyy options. >> >> A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> >> and >> BASE_LIB_tune-<name> to control the multilib location. All options can be >> overridden >> by the distro or local user configuration. >> >> Signed-off-by: Richard Purdie <[email protected]> > > As a specific nit, we can't use x86_64 in OVERRIDES (using the normal > mechanism need base_contains(...). Can we switch to calling it amd64 > ala Debian/Ubuntu? Aside from that, as I told Mark the other day, this > looks good to me. >
I actually prefer "x86-64" I think that is a reasonable compromise between the x86_64 naming and the need to not use "_". --Mark _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
