* [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir @ 2014-02-06 4:02 Darren Hart 2014-02-06 4:30 ` Bruce Ashfield 0 siblings, 1 reply; 4+ messages in thread From: Darren Hart @ 2014-02-06 4:02 UTC (permalink / raw) To: openembedded-core; +Cc: Darren Hart The current linux-yocto build dir (B) includes MACHINE. This has been appropriate as kernels are typically built machine-specific. We have recently introduced an intel-common type kernel which can be shared across multiple machines sharing a common base (intel-core2-32, intel-corei7-64). In these cases, the kernel is built for a something more generic than MACHINE, and the current mechanism results in something like this when building for MACHINE=sys940x (using intel-common): tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ 3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-build Note the descrepancy between core2-32-intel-common and linux-sys940x-noemgd-standard-build. This becomes counterintuitive at the very least when switching to another machine and attempting to reuse this build. This patch swaps MACHINE for PACKAGE_ARCH (which is typically MACHINE_ARCH for linux-yocto), resulting in the following build path: tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ 3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-standard-build The impact to existing MACHINEs is a replace of - with _ if MACHINE contains one or more - charachters. Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> --- meta/recipes-kernel/linux/linux-yocto.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc index 2bee042..4ed3188 100644 --- a/meta/recipes-kernel/linux/linux-yocto.inc +++ b/meta/recipes-kernel/linux/linux-yocto.inc @@ -31,7 +31,7 @@ inherit kernel inherit kernel-yocto require linux-dtb.inc -B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" +B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" do_install_append(){ if [ -n "${KMETA}" ]; then -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir 2014-02-06 4:02 [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir Darren Hart @ 2014-02-06 4:30 ` Bruce Ashfield 2014-02-06 5:20 ` Darren Hart 0 siblings, 1 reply; 4+ messages in thread From: Bruce Ashfield @ 2014-02-06 4:30 UTC (permalink / raw) To: Darren Hart; +Cc: Patches and discussions about the oe-core layer On Wed, Feb 5, 2014 at 11:02 PM, Darren Hart <dvhart@linux.intel.com> wrote: > The current linux-yocto build dir (B) includes MACHINE. This has been > appropriate as kernels are typically built machine-specific. We have > recently introduced an intel-common type kernel which can be shared > across multiple machines sharing a common base (intel-core2-32, > intel-corei7-64). In these cases, the kernel is built for a something > more generic than MACHINE, and the current mechanism results in > something like this when building for MACHINE=sys940x (using intel-common): > > tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ > 3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-build > > Note the descrepancy between core2-32-intel-common and > linux-sys940x-noemgd-standard-build. This becomes counterintuitive at > the very least when switching to another machine and attempting to reuse > this build. This patch swaps MACHINE for PACKAGE_ARCH (which is > typically MACHINE_ARCH for linux-yocto), resulting in the following > build path: > > tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ > 3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-standard-build > > The impact to existing MACHINEs is a replace of - with _ if MACHINE > contains one or more - charachters. > > Signed-off-by: Darren Hart <dvhart@linux.intel.com> > Cc: Bruce Ashfield <bruce.ashfield@windriver.com> > Cc: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > meta/recipes-kernel/linux/linux-yocto.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > index 2bee042..4ed3188 100644 > --- a/meta/recipes-kernel/linux/linux-yocto.inc > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > @@ -31,7 +31,7 @@ inherit kernel > inherit kernel-yocto > require linux-dtb.inc > > -B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" > +B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" But for truly machine specific kernel builds, won't this cause us collisions ? Bruce > > do_install_append(){ > if [ -n "${KMETA}" ]; then > -- > 1.7.9.5 > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir 2014-02-06 4:30 ` Bruce Ashfield @ 2014-02-06 5:20 ` Darren Hart 2014-02-06 5:27 ` Bruce Ashfield 0 siblings, 1 reply; 4+ messages in thread From: Darren Hart @ 2014-02-06 5:20 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer On 2/5/14, 20:30, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote: >On Wed, Feb 5, 2014 at 11:02 PM, Darren Hart <dvhart@linux.intel.com> >wrote: >> The current linux-yocto build dir (B) includes MACHINE. This has been >> appropriate as kernels are typically built machine-specific. We have >> recently introduced an intel-common type kernel which can be shared >> across multiple machines sharing a common base (intel-core2-32, >> intel-corei7-64). In these cases, the kernel is built for a something >> more generic than MACHINE, and the current mechanism results in >> something like this when building for MACHINE=sys940x (using >>intel-common): >> >> tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ >> >>3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-b >>uild >> >> Note the descrepancy between core2-32-intel-common and >> linux-sys940x-noemgd-standard-build. This becomes counterintuitive at >> the very least when switching to another machine and attempting to reuse >> this build. This patch swaps MACHINE for PACKAGE_ARCH (which is >> typically MACHINE_ARCH for linux-yocto), resulting in the following >> build path: >> >> tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ >> >>3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-sta >>ndard-build >> >> The impact to existing MACHINEs is a replace of - with _ if MACHINE >> contains one or more - charachters. >> >> Signed-off-by: Darren Hart <dvhart@linux.intel.com> >> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> >> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> >> --- >> meta/recipes-kernel/linux/linux-yocto.inc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc >>b/meta/recipes-kernel/linux/linux-yocto.inc >> index 2bee042..4ed3188 100644 >> --- a/meta/recipes-kernel/linux/linux-yocto.inc >> +++ b/meta/recipes-kernel/linux/linux-yocto.inc >> @@ -31,7 +31,7 @@ inherit kernel >> inherit kernel-yocto >> require linux-dtb.inc >> >> -B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" >> +B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" > >But for truly machine specific kernel builds, won't this cause us >collisions ? I don't see how. Note the build paths above. For truly machine-specifc builds, the WORKDIR is already machine-specific (because the PACKAGE_ARCH is MACHINE_ARCH), so there is no need to specify the MACHINE in the S or B dirs really at all. In fact, just calling this linux-build without any other modifier would be fine I think. What I attempted here was in keeping with the intent of the design: identify what we are building for in the B dir. -- Darren ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir 2014-02-06 5:20 ` Darren Hart @ 2014-02-06 5:27 ` Bruce Ashfield 0 siblings, 0 replies; 4+ messages in thread From: Bruce Ashfield @ 2014-02-06 5:27 UTC (permalink / raw) To: Darren Hart; +Cc: Patches and discussions about the oe-core layer On Thu, Feb 6, 2014 at 12:20 AM, Darren Hart <dvhart@linux.intel.com> wrote: > On 2/5/14, 20:30, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote: > >>On Wed, Feb 5, 2014 at 11:02 PM, Darren Hart <dvhart@linux.intel.com> >>wrote: >>> The current linux-yocto build dir (B) includes MACHINE. This has been >>> appropriate as kernels are typically built machine-specific. We have >>> recently introduced an intel-common type kernel which can be shared >>> across multiple machines sharing a common base (intel-core2-32, >>> intel-corei7-64). In these cases, the kernel is built for a something >>> more generic than MACHINE, and the current mechanism results in >>> something like this when building for MACHINE=sys940x (using >>>intel-common): >>> >>> tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ >>> >>>3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-b >>>uild >>> >>> Note the descrepancy between core2-32-intel-common and >>> linux-sys940x-noemgd-standard-build. This becomes counterintuitive at >>> the very least when switching to another machine and attempting to reuse >>> this build. This patch swaps MACHINE for PACKAGE_ARCH (which is >>> typically MACHINE_ARCH for linux-yocto), resulting in the following >>> build path: >>> >>> tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \ >>> >>>3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-sta >>>ndard-build >>> >>> The impact to existing MACHINEs is a replace of - with _ if MACHINE >>> contains one or more - charachters. >>> >>> Signed-off-by: Darren Hart <dvhart@linux.intel.com> >>> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> >>> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> >>> --- >>> meta/recipes-kernel/linux/linux-yocto.inc | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc >>>b/meta/recipes-kernel/linux/linux-yocto.inc >>> index 2bee042..4ed3188 100644 >>> --- a/meta/recipes-kernel/linux/linux-yocto.inc >>> +++ b/meta/recipes-kernel/linux/linux-yocto.inc >>> @@ -31,7 +31,7 @@ inherit kernel >>> inherit kernel-yocto >>> require linux-dtb.inc >>> >>> -B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" >>> +B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" >> >>But for truly machine specific kernel builds, won't this cause us >>collisions ? > > I don't see how. Note the build paths above. For truly machine-specifc > builds, the WORKDIR is already machine-specific (because the PACKAGE_ARCH > is MACHINE_ARCH), so there is no need to specify the MACHINE in the S or B > dirs really at all. In fact, just calling this linux-build without any > other modifier would be fine I think. What I attempted here was in keeping > with the intent of the design: identify what we are building for in the B > dir. Right you are. For a machine specific kernel recipe, workdir will provide the separation. I missed that. And yes, even though it is a bit redundant, it is still nice to keep that extra identifier in the buildir name. So this is Ack'd from my side. Bruce > > -- > Darren > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-06 5:27 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-06 4:02 [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir Darren Hart 2014-02-06 4:30 ` Bruce Ashfield 2014-02-06 5:20 ` Darren Hart 2014-02-06 5:27 ` Bruce Ashfield
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox