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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core