diff options
author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-07-22 17:32:21 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-07-25 14:19:54 +0100 |
commit | 5f9d56bd64997b93ed7e46c117851002a0556654 (patch) | |
tree | 62bda73eb586628e9a395795fa10940ec09f28da /meta/classes/package.bbclass | |
parent | 92a7e70feb1dfd882d13b5cb65e144d293ff291a (diff) | |
download | openembedded-core-5f9d56bd64997b93ed7e46c117851002a0556654.tar.gz openembedded-core-5f9d56bd64997b93ed7e46c117851002a0556654.tar.bz2 openembedded-core-5f9d56bd64997b93ed7e46c117851002a0556654.tar.xz openembedded-core-5f9d56bd64997b93ed7e46c117851002a0556654.zip |
conf/machine/include: Start to fill out architecture specific tune include files and tune features
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 <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/package.bbclass')
0 files changed, 0 insertions, 0 deletions