openembedded-core.git/meta/conf/machine/include/ia32, branch 2011-1 Mirror of openembedded-core x86 tune inc files: add x32 abi tune parameters 2011-08-08T17:05:02+00:00 Nitin A Kamble nitin.a.kamble@intel.com 2011-07-23T00:18:47+00:00 19252e0592c59ed0fb06ca510d11e564518f746d Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> 
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
arch-ia32.inc: Fix up TUNE_ARCH variable conflicts 2011-07-26T21:39:49+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-07-26T17:51:02+00:00 02031d766f983cd7e01e468cb2c926604313cd2a The current approach causes duplicate values to appear in the TUNE_ARCH field and this patch addresses that. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The current approach causes duplicate values to appear in the TUNE_ARCH
field and this patch addresses that.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
conf/machine/include: Start to fill out architecture specific tune include files and tune features 2011-07-25T13:19:54+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2011-07-22T16:32:21+00:00 5f9d56bd64997b93ed7e46c117851002a0556654 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> 
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>