Currently the virtclass override is added too late to be taken into
account when DEPENDS and other variables are processed by the virtclass
extension code. This sets the overrides in a more optimal place, meaning
they are accounted for in variables like DEPENDS.

Recipes in meta-oe like libwmf-native showed the issue.

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

Since this class works on pre finalised data, the logic hasn't needed
to be exact. If we change the way the finalised data works, we find
that certain dependencies can be dropped (e.g. pn isn't in the name).

To fix this, restructure the function to alter each entry in turn
and not drop any entries.

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

The way native_virtclass_handler was implemented leaded to
unintended substring replacements when setting PROVIDES for
native providers, in case the original PROVIDES value contains
providees with common substrings.

Here's a practical case where the old behavior was problematic:
the oracle-jse-jdk-x86-64 recipe provides both virtual/java and
virtual/javac:

Before:

$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES="oracle-jse-jdk-x86-64-native  virtual/java-native virtual/java-nativec"

After:

$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES="oracle-jse-jdk-x86-64-native virtual/java-native virtual/javac-native"

Change-Id: I8186992dae58e37c2a2364586360ff9b7da9198f
Signed-off-by: Mario Domenech Goulart <mario@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>

If a recipe (say, wayland) has DEPENDS=wayland-native and BBCLASSEXTEND=native,
when built as wayland-native it has DEPENDS=wayland-native which results in a
circular dependency.

Typically this is resolved by having explicit DEPENDS_class-native statements
but as this is duplication which can lead to inconsistent dependencies,
automatically remove the circular dependency.

Signed-off-by: Ross Burton <ross.burton@intel.com>

Instead of replicating the logic for the host compiler naming from bitbake.conf,
use the BUILD_* variables directly.

Also change BUILD_CPP to use gcc -E (which native.bbclass previously used), as
some recipes (e.g. grub-efi) use ${CPP} with multiple input files, which gcc -E
can handle but cpp can't.

Signed-off-by: Ross Burton <ross.burton@intel.com>

The native recipe doesn't need package_qa, and it has a race issue with
do_unpack which requires the clean dir of ${S}, then causes error:

NOTE: recipe opkg-utils-native-0.1.8+gitAUTOINC+eae0d8fa44-r0: task do_package_qa: Failed
ERROR: Task 283 (virtual:native:/path/to/opkg-utils_git.bb, do_package_qa) failed with exit code '1'

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In cases where we override variables e.g PACKAGE_ARCH
conditionally and use a MACHINEOVERRIDE to qualify the
override like

PACKAGE_ARCH_<MACHINE> = "some target PACKAGE_ARCH"

This would also be effective if this recipe is
BBEXTENDED to native or nativesdk which is undesired
This particular issue will cause wrong sysroot to be
used for nativesdk case since PACKAGE_ARCH would have
been modified and eventually changing value of
STAGING_DIR_TARGET which we use as --sysroot option
to cross and cross-canadian built SDK gcc

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

For most users this commit will have no effect. But if you come across the idea of giving
different names for paths, you'll get some troubles.

When a recipe inherit native, properly define bindir, sbindir, includedir, sysconfdir, datadir
(using xxxdir_native definitions from meta/conf/bitbake.conf).

For example, edit "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/quilt-native/temp/log.do_configure"
and see what are the arguments given by oe_runconf.

Notice that ${docdir}, ${mandir}, ${infodir}, ${localstatedir} have no associated _native definition.

Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

With the renaming of the cross packages, its no longer possible to use
endswith("-cross") and similar to detect cross packages. Replace these
references with other techniques.

This resolves certain build from sstate failures which were due to the
system believing cross packages were target packages and therefore
dependency handling was altered.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

TARGET_LDFLAGS is currently defined in bitbake.conf to contain
${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
targets. Since TARGET_LDFLAGS is an exported variable it affects the hash
of every shell task even if it is not used.

We don't want native recipe tasks to have different hashes purely because
they happen to have been built in order to satisfy dependencies for
different MACHINEs since this causes lots of churn in the native sysroot
when switching between MACHINEs.

Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS ensures
consistent hashes and is a sensible thing to be doing anyway.

Although they don't appear to have the same detrimental affect on task
hashes TARGET_CPPFLAGS, TARGET_CFLAGS and TARGET_CXXFLAGS should be
overridden too.

Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>