| 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
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.
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 >
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 ?
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!
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
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"
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(-)