Martin Jansa 60589dd60c conf/machine: use .= instead of += in TUNE_CCARGS
* number of TUNE_CCARGS conditionals is important if we add
  extra space with each one in "else" branch

  I'm building for 2 MACHINEs one is cortexa9, second is cortexa8

  few months ago we added TUNE_CCARGS[vardepvalue] in bitbake.conf
  http://git.openembedded.org/openembedded-core/commit/?id=03f1e34ea3ce80931e9c3cd2ab22824f28a7233b

  which fixed some cases (like mentioned tune-xscale and tune-arm926ejs)
  where both had unused TUNE_CCARGS when common DEFAULTTUNE was used.

  with cortexa[89] it's different, because cortexa9 has one extra TUNE_CCARGS
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex-a9", "", d)}"
  which adds extra *space* even when not used because of '+=' and as result:

  $ bitbake-diffsigs tmp-eglibc/sstate-diff/1366797730/*/armv7*/adapterbase/*do_configure*
  basehash changed from f986789fb8fb3579ed6a3492cc8a8d10 to c851b5f838d945ee13072e9ad6725dca
  Variable TUNE_CCARGS value changed from
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon '
  to
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon  '
  Hash for dependent task gcc-runtime_4.7.bb.do_populate_sysroot changed from bdeabf7a86958b9110b566344b7916de to 2be5618e6bc8c57ec9db5659bf217915
  Hash for dependent task eglibc_2.17.bb.do_populate_sysroot changed from b4f40fc62dde684acd0a574532a55360 to 97fcb426603d4a1c1099c0504d2ebf7d
  Hash for dependent task glib-2.0_2.34.3.bb.do_populate_sysroot changed from fd2f90b83098c34e88d649d70f6ea4f5 to ebd740bb94ea3eb0a914efda6fc82c4a

(From OE-Core rev: b7430ff83760ac29079d20dc7c62f498a0a9d55d)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-04-29 14:45:06 +01:00
..

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 
configuration.

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 
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 
in the AVAILTUNES.

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>.
New sanity checks will try to reject combinations in which a single
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 
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 
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. 
${@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.  
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 
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 
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 
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 
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, 
non-conflicting locations.