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. -- Tom Rini Mentor Graphics Corporation _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
