summaryrefslogtreecommitdiff
path: root/meta
diff options
context:
space:
mode:
authorDarren Hart <dvhart@linux.intel.com>2014-01-17 22:26:21 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-01-28 00:48:22 +0000
commit112e291c14ce4c3b8d074b71e63500dce609784e (patch)
tree9708728d9b538e87253f03aeb56c097d7eb0310d /meta
parentd8884649b2b3e76519bc10f5908f98d940a9c0cb (diff)
downloadopenembedded-core-112e291c14ce4c3b8d074b71e63500dce609784e.tar.gz
openembedded-core-112e291c14ce4c3b8d074b71e63500dce609784e.tar.bz2
openembedded-core-112e291c14ce4c3b8d074b71e63500dce609784e.zip
tune: README: Whitespace cleanup
Before making content changes, cleanup the various whitespace errors in this file. Mostly end-of-line whitepsace. Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Paul Eggleton <paul.eggleton@intel.com> Cc: Tom Zanussi <tom.zanussi@intel.com> Cc: Nitin Kamble <nitin.a.kamble@intel.com> Cc: Mark Hatle <mark.hatle@windriver.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Cc: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta')
-rw-r--r--meta/conf/machine/include/README88
1 files changed, 44 insertions, 44 deletions
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index e4b59c9566..65d09428a8 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -1,27 +1,27 @@
2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
- Initial Revision
-The individual CPU, and ABI tunings are contained in this directory. A
-number of local and global variables are used to control the way the
-tunings are setup and how they work together to specify an optimized
+The individual CPU, and ABI tunings are contained in this directory. A
+number of local and global variables are used to control the way the
+tunings are setup and how they work together to specify an optimized
configuration.
-The following is brief summary of the generic components that are used
+The following is brief summary of the generic components that are used
in these tunings.
-AVAILTUNES - This is a list of all of the tuning definitions currently
-available in the system. Not all tunes in this list may be compatible
-with the machine configuration, or each other in a multilib
-configuration. Each tuning file can add to this list using "+=", but
+AVAILTUNES - This is a list of all of the tuning definitions currently
+available in the system. Not all tunes in this list may be compatible
+with the machine configuration, or each other in a multilib
+configuration. Each tuning file can add to this list using "+=", but
should never replace the list using "=".
-DEFAULTTUNE - This specifies the tune to use for a particular build.
-Each tune should specify a reasonable default, which can be overriden by
-a machine or multilib configuration. The specified tune must be listed
+DEFAULTTUNE - This specifies the tune to use for a particular build.
+Each tune should specify a reasonable default, which can be overriden by
+a machine or multilib configuration. The specified tune must be listed
in the AVAILTUNES.
-TUNEVALID[feature] - The <feature> is defined with a human readable
-explanation for what it does. All architectural, cpu, abi, etc tuning
+TUNEVALID[feature] - The <feature> is defined with a human readable
+explanation for what it does. All architectural, cpu, abi, etc tuning
features must be defined using TUNEVALID.
TUNECONFLICTS[feature] - A list of features which conflict with <feature>.
@@ -31,51 +31,51 @@ tuning ends up with features which conflict with each other.
TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-<tune>.
See TUNE_FEATURES_tune-<tune> for more information.
-TUNE_FEATURES_tune-<tune> - Specify the features used to describe a
-specific tune. This is a list of features that a tune support, each
-feature must be in the TUNEVALID list. Note: the tune and a given
-feature name may be the same, but they have different purposes. Only
-features may be used to change behavior, while tunes are used to
+TUNE_FEATURES_tune-<tune> - Specify the features used to describe a
+specific tune. This is a list of features that a tune support, each
+feature must be in the TUNEVALID list. Note: the tune and a given
+feature name may be the same, but they have different purposes. Only
+features may be used to change behavior, while tunes are used to
describe an overall set of features.
-ABIEXTENSION - An ABI extension may be specified by a specific feature
-or other tuning setting, such as TARGET_FPU. Any ABI extensions either
-need to be defined in the architectures base arch file, i.e.
-ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune
+ABIEXTENSION - An ABI extension may be specified by a specific feature
+or other tuning setting, such as TARGET_FPU. Any ABI extensions either
+need to be defined in the architectures base arch file, i.e.
+ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune
files with a ".=". Spaces are not allowed in this variable.
-TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
-These should be additive when defined using "+=". All items in this
-list should be dynamic! i.e.
+TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
+These should be additive when defined using "+=". All items in this
+list should be dynamic! i.e.
${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)}
-TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
-arm, armeb, mips, mips64, etc. This value is by bitbake to setup
-configure. TUNE_ARCH definitions are specific to a given architecture.
-They may be a single static definitions, or may be dynamically adjusted.
+TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
+arm, armeb, mips, mips64, etc. This value is by bitbake to setup
+configure. TUNE_ARCH definitions are specific to a given architecture.
+They may be a single static definitions, or may be dynamically adjusted.
See each architectures README for details for that CPU family.
-TUNE_PKGARCH - The package architecture used by the packaging systems to
-define the architecture, abi and tuning of a particular package.
-Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to
-each architecture. See each architectures README for details for that
+TUNE_PKGARCH - The package architecture used by the packaging systems to
+define the architecture, abi and tuning of a particular package.
+Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to
+each architecture. See each architectures README for details for that
CPU family.
-PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package
-architectures. By default this is equal to
-PACKAGE_EXTRA_ARCHS_tune-<tune>. If an architecture deviates from the
+PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package
+architectures. By default this is equal to
+PACKAGE_EXTRA_ARCHS_tune-<tune>. If an architecture deviates from the
default it will be listed in the architecture README.
-PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures
-that are compatible with this specific tune. The package arch of this
+PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures
+that are compatible with this specific tune. The package arch of this
tune must be in the list.
-TARGET_FPU - The FPU setting for a given tune, hard (generate floating
-point instructions), soft (generate internal gcc calls), "other"
-architecture specific floating point. This is synchronized with the
-compiler and other toolchain items. This should be dynamically
+TARGET_FPU - The FPU setting for a given tune, hard (generate floating
+point instructions), soft (generate internal gcc calls), "other"
+architecture specific floating point. This is synchronized with the
+compiler and other toolchain items. This should be dynamically
configured in the same way that TUNE_CCARGS is.
-BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI. This is
-used in a multilib configuration to place the libraries in the correct,
+BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI. This is
+used in a multilib configuration to place the libraries in the correct,
non-conflicting locations.