bitbake.conf: Drop obsolete FILESDIR setting

FILESPATH is the preferred way of finding files now. Having a value
for FILESDIR which defaults to paths which will have already been
searched is pointless at best. This is the final step in letting
us drop FILESDIR support entirely from bitbake at some future date.

(From OE-Core rev: d6e5ceafcaef06b8a3f9acc2aa826a40a016f913)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake.conf: Simplify FILESPATH

Files are very rarely, if ever placed in ${PF}. If a recipe needs to do this,
it can easily append to FILESPATH so it makes sense to drop this from the
default search path.

Equally, using FILE_DIR as part of the search path leads to 'bad' SRC_URI
entries and/or file layouts which are not preferred. I'm therefore of the
opinion we should also remove this from FILESPATH and encourage people to
cleanup any places this breaks my correcting the layouts to match the standard
or worst case adding to FILESPATH in recipes that need it.

These changes work towards making the system more friendly as users won't be
greeted with huge search paths we rearely use making the "correct" layout
more obvious.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
base.bbclass: Drop P and PN from FILESPATH

In the interests of simplifying things, remove P and PN from FILESPATH,
instead relying on the BP and BPN versions which work in 99% of cases.

In any problematic case such as a -native only recipe, either the patch
directory can be renamed or the recipe can set FILESPATH specifically.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes

* tune-foo is not valid override, for it to work I had to add
  ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
  but that doesn't work without value defined for every supported
  DEFAULTTUNE value, otherwise it's expanded like this
  TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-arm: define different ARMPKGARCH when different CCARGS are used

* without this tune-xscale and tune-arm926ejs were both creating
  packages in armv5te feed, but each with different -mtune, with
  OEBasicHash enabled it was causing each package to rebuild with new
  -mtune after MACHINE switch, but that doesn't make sense with output
  stored in the same armv5te feed

* this makes different feed for each -mtune, but more generic one to be
  selected with DEFAULTTUNE

* tune-iwmmxt and tune-ep9312 were already using this, just move it
  bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax

* tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH
  because there isn't another tune to use the same -march

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tune-*: define more generic DEFAULTTUNE to share feed between machines

* this is mostly for backwards compatibility and to share binary feed
  like it was before, but now without missing different -mtune in it
* if you want to build some package with -mtune add something like this
  to your distro config
  DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs"
  DEFAULTTUNE_qemuarmx_pn-openssl = "xscale"
  be aware that if you do this you should do it also for all packages
  which depends on openssl because if you dont and you build e.g. dhcp,
  then dhcp build for arm926ejs (even with DEFAULTTUNE armv5te) will
  depend on openssl with arm926ejs, so dhcp in armv5te feed will be
  rebuild after each MACHINE switch.
* cortexm3, cortexr4, iwmmx and ep9312 are using own DEFAULTTUNE because
  they define also different -march
* shared feeds are
  armv4t: arm920t, arm9tdmi
  armv5te: arm926ejs, xscale
  armv7a-neon: cortexa8, cortexa9

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
automake: update to upstream version 1.12.5

Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
allarch: Allow class to be included but overridden

We have cases where we'd like to inherit this class by default but allow
special cases to override it. This change makes the code of the class
conditional on PACKAGE_ARCH remaining set to "all", allowing it to be
overridden. packagegroup usage is one case this is desirable.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
packagegroup/allarch: Convert to use allarch class

Currently there is some odd behaviour of the packagegroup class in relation
to sstate since it sets PACKAGE_ARCH = "all" but does not use the allarch class
leading to it being undetected by sstate.

Previously it was not possible to use allarch as the recipe couldn't "undo"
settings made by the allarch class. Since this no longer happens when
PACKAGE_ARCH != all, we can use the allarch class.

This patch also fixes up one case we need to preserve TRANSLATED_TARGET_ARCH
and ensures sstate only assumes allarch when PACKAGE_ARCH is "all".

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>