[OE-core] Patterns in the hackery various classes need - Need API change?

[Richard Purdie]

I've spent quite a bit of time recently staring at the insanity that
some of our core classes have. That code generally works so people like
to leave it well alone but when you look at some of it, there is some
nasty stuff going on.

Taking cross.bbclass as an example:

  # Save PACKAGE_ARCH before changing HOST_ARCH
  OLD_PACKAGE_ARCH := "${PACKAGE_ARCH}"
  PACKAGE_ARCH = "${OLD_PACKAGE_ARCH}"
  # Also save BASE_PACKAGE_ARCH since HOST_ARCH can influence it
  OLD_BASE_PACKAGE_ARCH := "${BASE_PACKAGE_ARCH}"
  BASE_PACKAGE_ARCH = "${OLD_BASE_PACKAGE_ARCH}"
  BASEPKG_HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"

nativesdk.bbclass:

  # Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
  #
  OLD_PACKAGE_ARCH := ${BASE_PACKAGE_ARCH}
  BASE_PACKAGE_ARCH = "${SDK_ARCH}-nativesdk"

Then we have the code in base.bbclass and bitbake.conf which plays with
MULTIMACH_ARCH which as far as I can figure out is totally broken. I
have a patch I'm experimenting with to just remove that variable out.

Bottom line, we really need the machine/tune/architecture files to set
variables which we don't mess with and derive all our others from these.

The machine/tune/architecture files really need to specify two things
which in today's variable terms are:

a) The TARGET_ARCH value which is really the broad architecture
b) The BASE_PACKAGE_ARCH which is what things compiled with the tune 
   flags should get packaged as.

The problem is we need to change TARGET_ARCH under a number of
circumstances and BASE_PACKAGE_ARCH defaults to being derived from
TARGET_ARCH so that is also easily "broken".

I'm seriously considering coming up with two new variable names and then
having bitbake exit if the machine/tune/architecture files don't define
these. We could then likely simplify some of the core code and make it
much more plain what was going on. Something like:

TARGET_BASEARCH = "arm"
TARGET_PKGARCH = "armv7a"

Would this be too painful for people or something we could do? Most
people are likely using the core tune-* files which should make this
transition a bit less painful...

Cheers,

Richard