Patchwork [2/4] linux-tools: don't build perf when GPLv3 in INCOMPATIBLE_LICENSE

login
register
mail settings
Submitter Joshua Lock
Date Jan. 24, 2012, 11:26 p.m.
Message ID <f7bd8523525f541676e8b2e416a4960b45cd7d7e.1327447344.git.josh@linux.intel.com>
Download mbox | patch
Permalink /patch/20091/
State New
Headers show

Comments

Joshua Lock - Jan. 24, 2012, 11:26 p.m.
As binutils is required by perf to build and is GPLv3 licensed adding
GPLv3 to INCOMPATIBLE_LICENSE will cause linux-yocto to be skipped.

Long term we should look at moving perf to a separate recipe but as a
short term solution this patch will ensure that when GPLv3 is in
INCOMPATIBLE_LICENSE perf is not built and it's dependencies are not
added to build.

Fixes [YOCTO #1880]

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/recipes-kernel/linux/linux-tools.inc       |   20 ++++++++++++++++++--
 meta/recipes-kernel/linux/linux-yocto_2.6.37.bb |    2 +-
 meta/recipes-kernel/linux/linux-yocto_3.0.bb    |    2 +-
 3 files changed, 20 insertions(+), 4 deletions(-)
Khem Raj - Jan. 24, 2012, 11:42 p.m.
On Tue, Jan 24, 2012 at 3:26 PM, Joshua Lock <josh@linux.intel.com> wrote:
> Long term we should look at moving perf to a separate recipe but as a
> short term solution this patch will ensure that when GPLv3 is in

would I be asking too much to do that instead of this patch :)
I think it will be good thing in general since other layers
now have to define these tasks if they inherit from oe-core kernel class.
Saul Wold - Jan. 24, 2012, 11:59 p.m.
On 01/24/2012 03:42 PM, Khem Raj wrote:
> On Tue, Jan 24, 2012 at 3:26 PM, Joshua Lock<josh@linux.intel.com>  wrote:
>> Long term we should look at moving perf to a separate recipe but as a
>> short term solution this patch will ensure that when GPLv3 is in
>
> would I be asking too much to do that instead of this patch :)
> I think it will be good thing in general since other layers
> now have to define these tasks if they inherit from oe-core kernel class.
>
Khem,

The issue is timing and resources to do this work, it a larger task that 
may take more than a few days to refactor perf into it's own recipe and 
share the source area (ala work-shared/gcc).  We need to get the 
non-GPLv3 build working again and this seems like the most direct route 
to accomplish that.

Sau!


> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Khem Raj - Jan. 25, 2012, 1:04 a.m.
On Tue, Jan 24, 2012 at 3:59 PM, Saul Wold <sgw@linux.intel.com> wrote:
>
>
> The issue is timing and resources to do this work, it a larger task that may
> take more than a few days to refactor perf into it's own recipe and share
> the source area (ala work-shared/gcc).  We need to get the non-GPLv3 build
> working again and this seems like the most direct route to accomplish that.

is that a blocker for oe-core ?
Saul Wold - Jan. 25, 2012, 1:10 a.m.
On 01/24/2012 05:04 PM, Khem Raj wrote:
> On Tue, Jan 24, 2012 at 3:59 PM, Saul Wold<sgw@linux.intel.com>  wrote:
>>
>>
>> The issue is timing and resources to do this work, it a larger task that may
>> take more than a few days to refactor perf into it's own recipe and share
>> the source area (ala work-shared/gcc).  We need to get the non-GPLv3 build
>> working again and this seems like the most direct route to accomplish that.
>
> is that a blocker for oe-core ?
>
It's a blocker for oe-core & 1.2, and we are not sure get can get the 
refactor done by 1.2 given all the the other activities the team has, if 
there are some external resources available o complete this work, that 
would be very helpful!

Sau!
Andrei Gherzan - Jan. 25, 2012, 10:11 a.m.
On 01/25/2012 01:59 AM, Saul Wold wrote:
> On 01/24/2012 03:42 PM, Khem Raj wrote:
>> On Tue, Jan 24, 2012 at 3:26 PM, Joshua Lock<josh@linux.intel.com>  
>> wrote:
>>> Long term we should look at moving perf to a separate recipe but as a
>>> short term solution this patch will ensure that when GPLv3 is in
>>
>> would I be asking too much to do that instead of this patch :)
>> I think it will be good thing in general since other layers
>> now have to define these tasks if they inherit from oe-core kernel 
>> class.
>>
> Khem,
>
> The issue is timing and resources to do this work, it a larger task 
> that may take more than a few days to refactor perf into it's own 
> recipe and share the source area (ala work-shared/gcc).  We need to 
> get the non-GPLv3 build working again and this seems like the most 
> direct route to accomplish that.
>
> Sau!
>

This is a good workaround for this bug. Obviously a "refactor way" would 
be a better one in my opinion too. But for now, as this bug breaks a 
non-GPLv3 build, a fast solution, like this, is needed.


@g
Richard Purdie - Jan. 25, 2012, 12:31 p.m.
On Tue, 2012-01-24 at 15:26 -0800, Joshua Lock wrote:
> As binutils is required by perf to build and is GPLv3 licensed adding
> GPLv3 to INCOMPATIBLE_LICENSE will cause linux-yocto to be skipped.
> 
> Long term we should look at moving perf to a separate recipe but as a
> short term solution this patch will ensure that when GPLv3 is in
> INCOMPATIBLE_LICENSE perf is not built and it's dependencies are not
> added to build.
> 
> Fixes [YOCTO #1880]
> 
> Signed-off-by: Joshua Lock <josh@linux.intel.com>
> ---
>  meta/recipes-kernel/linux/linux-tools.inc       |   20 ++++++++++++++++++--
>  meta/recipes-kernel/linux/linux-yocto_2.6.37.bb |    2 +-
>  meta/recipes-kernel/linux/linux-yocto_3.0.bb    |    2 +-
>  3 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc
> index aa45dba..69e68c0 100644
> --- a/meta/recipes-kernel/linux/linux-tools.inc
> +++ b/meta/recipes-kernel/linux/linux-tools.inc
> @@ -1,5 +1,18 @@
>  # included by kernel recipes if they want to build/provide
>  # perf functionality from their tree.
> +
> +# perf requires binutils which is GPLv3 licensed, don't prevent the entire kernel
> +# being built if GPLv3 is in INCOMPATIBLE_LICENSE
> +python () {
> +    d.setVar("BUILDPERF", "yes")
> +    d.setVar("PERFDEPENDS", "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot ${MLPREFIX}binutils:do_populate_sysroot")
> +
> +    if ((d.getVar("INCOMPATIBLE_LICENSE", True) or "").find("GPLv3") != -1):
> +       # GPLv3, drop perf
> +       d.setVar("BUILDPERF", "no")
> +       d.setVar("PERFDEPENDS", "")
> +}
> +

Can we make this a little neater, something like:

BUILDPERF = "yes"
BUILDPERF_libc-uclib = "no"
PERFDEPENDS = "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot ${MLPREFIX}binutils:do_populate_sysroot"
PERFDEPENDS_libc-uclibc = ""

Then just have the if statement in the anonymous python and drop the
do_compile_perf_libc-uclibc and PERFDEPENDS_libc-uclibc.

This also makes it easy for an external recipe to just disable this
code.

Cheers,

Richard

Patch

diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc
index aa45dba..69e68c0 100644
--- a/meta/recipes-kernel/linux/linux-tools.inc
+++ b/meta/recipes-kernel/linux/linux-tools.inc
@@ -1,5 +1,18 @@ 
 # included by kernel recipes if they want to build/provide
 # perf functionality from their tree.
+
+# perf requires binutils which is GPLv3 licensed, don't prevent the entire kernel
+# being built if GPLv3 is in INCOMPATIBLE_LICENSE
+python () {
+    d.setVar("BUILDPERF", "yes")
+    d.setVar("PERFDEPENDS", "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot ${MLPREFIX}binutils:do_populate_sysroot")
+
+    if ((d.getVar("INCOMPATIBLE_LICENSE", True) or "").find("GPLv3") != -1):
+       # GPLv3, drop perf
+       d.setVar("BUILDPERF", "no")
+       d.setVar("PERFDEPENDS", "")
+}
+
 do_compile_perf_libc-uclibc () {
 	:
 }
@@ -7,11 +20,15 @@  do_install_perf_libc-uclibc () {
 	:
 }
 do_compile_perf() {
+    if [ "${BUILDPERF}" = "yes" ]; then
 	oe_runmake -C ${S}/tools/perf CC="${CC}" LD="${LD}" prefix=${prefix} NO_NEWT=1 NO_DWARF=1
+    fi
 }
 
 fakeroot do_install_perf() {
+    if [ "${BUILDPERF}" = "yes" ]; then
 	oe_runmake -C ${S}/tools/perf CC="${CC}" LD="${LD}" prefix=${prefix} DESTDIR=${D} install NO_NEWT=1 NO_DWARF=1
+    fi
 }
 
 
@@ -22,9 +39,8 @@  addtask install_perf after do_install before do_package
 do_compile_perf[umask] = 022
 do_install_perf[umask] = 022
 
-PERFDEPENDS = "virtual/${MLPREFIX}libc:do_populate_sysroot ${MLPREFIX}elfutils:do_populate_sysroot ${MLPREFIX}binutils:do_populate_sysroot"
-PERFDEPENDS_libc-uclibc = ""
 PERFRDEPENDS = "python perl elfutils"
 PERFRDEPENDS_libc-uclibc = ""
 do_compile_perf[depends] = "${PERFDEPENDS}"
+do_compile_perf_libc-uclibc[depends] = ""
 RDEPENDS_perf += "${PERFRDEPENDS}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
index 34e563c..ce71393 100644
--- a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
@@ -20,7 +20,7 @@  SRCREV_machine_qemux86-64 = "af2bfbe5f757361b5b027a24d67a93bfdfaaf33c"
 SRCREV_machine = "4ae8f8605c81c39b959948e23f7123294a5dfb3f"
 SRCREV_meta = "aeea99683c7283f1f3320bf2ee7085ee252d4e7e"
 
-PR = "r21"
+PR = "r22"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
index 10859e7..9d51bd0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -21,7 +21,7 @@  SRCREV_machine_qemux86-64 ?= "3551fd0412965b1f6b0b2f6ba35f7fecdaddb58a"
 SRCREV_machine ?= "6f5b11830deba4a6262c8c4abf67e608924f649e"
 SRCREV_meta ?= "665fea1c249b4f335cb1c9a46a9f2c138d611f1a"
 
-PR = "r2"
+PR = "r3"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"