This patch brings the last bit from meta-mentor for the perf
to build successfully with minnowmax BSP. The meta-mentor
commit for the same is:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/meta-mentor-staging?id=a8db95c0d4081cf96915e0c3c4063a44f55e21cc

The previous fix:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/perf?id=ef942d6025e1a339642b10ec1e29055f4ee6bd46
was incomplete and was not submitted upstream. And due to that this change is required.

When built on minnowmax ( machine name: intel-corei7-64),
an error is noticed during the do_compile:

 /home/sujith/codebench-linux-install-2015.12-133-i686-pc-linux-gnu/codebench/bin/i686-pc-linux-gnu-ld:
Relocatable linking with relocations from format elf64-x86-64
(/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/array.o)
to format elf32-i386 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/libapi-in.o)
is not supported

This change help fix the issue.

Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

When built on an i686 host for qemux86-64 without the
fix to obey LD and it fails:

/scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld:
Relocatable linking with relocations from format elf64-x86-64
(/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o)
to format elf32-i386 (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o)
is not supported

This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS,
which is -m elf32_x86_64 for x86_64. Without that, direct use of ld will fail.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

commit 4842576cd857 [perf tools: Move config/Makefile into Makefile.config]
relocated the configuration Makefile of perf. As such, we need to adapt
our fixup routines to work with the Makefile no matter where it is.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

For thoese recipes that are inheriting python*-dir.bbclass, there is
already a PYTHON_SITEPACKAGES_DIR present, use that definition replacing
redundant "${libdir}/python*/site-packages".

Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

When using 'perf help <subcommand>', it can't find 'man' command and pages for
perf.
The perf man pages depends on the xmlto-native and asciidoc-native, so we just
need to add the two packages to the DEPENDS variable and add 'man'to
RDEPENDS_perf-doc.

Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

We patch Python's distutils modules to access STAGING_INCDIR/LIBDIR, so when
they are not set, scripts that utilize distutils (e.g. python-config) fail.
Several recipes need to export those manually to prevent such failures,
so let's do that in the class instead.

PYTHON variable is exported because otherwise autotools' python.m4
macro will pick up its own internal default, which may not be the version
that we want.

glib recipe in particular was previously using Python 2.x during build due to python.m4
defaulting to it - now it's using Python 3.x, and so needs a small fix in
deletion of *.pyc files.

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The code that utilized them was superseded by the code (in the same patch!)
that is utilizing STAGING_LIBDIR/STAGING_INCDIR, and wasn't correct in the
first place as HOST_SYS is not necessarily the same as the sysroot directory
name.

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>

Instead of passing DESTDIR just in the make install invocation, pass it in
EXTRA_OEMAKE.  This appears to stop perf from rebuilding at instal time for me,
which appears to be the trigger for the random build failure.

[ YOCTO #9182 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The scripts that are part of perf require python and supporting modules.
The existing perf-pyton dependency only brought in core python, which
left us unable to actually execute the scripts on target.

With this additional runtime dependency, we can now execte the sample
analysis scripts when perf-scripting is availble.

This is a partial fix for [YOCTO #9069], since there are still scripts
looking for non-existent modules, and those will be dealt with in
future releases.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Two QA warnings were being generated from perf, due to the location of
python scripts changing in the kernel build:

WARNING: perf-1.0-r9 do_package_qa: QA Issue:
  /usr/libexec/perf-core/scripts/python/call-graph-from-postgresql.py contained
  in package perf-python requires /usr/bin/python2, but no providers found in RDEPENDS_perf-python? [file-rdeps]

WARNING: QA Issue: /usr/libexec/perf-core/tests/attr.py_perf contained in package
  perf requires /usr/bin/python, but no providers found in its RDEPENDS [file-rdeps]

By adding libexec dir to both the tests and scripts packaging, we get the
appropriate RDEPENDS on the packages that actually contain the python scripts
(without making perf-core depend on python).

We also tweak any python scripts to use '/usr/bin/env python', rather than a
version specific python, since it won't be provided and generate a QA error.

[YOCTO #8991]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>