| Submitter | Christopher Larson |
|---|---|
| Date | May 16, 2012, 1:25 a.m. |
| Message ID | <1337131523-8176-1-git-send-email-kergoth@gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/27793/ |
| State | Accepted |
| Commit | c1c8d2f3cffc540380c0a5fcdda48d64cbec333a |
| Headers | show |
Comments
On 05/15/2012 06:25 PM, Christopher Larson wrote: > From: Christopher Larson <chris_larson@mentor.com> > > It's common to provide a non-machine-suffixed link in DEPLOY_DIR_IMAGE, so > let's be consistent and do so here as well. This of course means that building two machines in the same build dir will result in overwriting the latest non-machine-suffixed link (provided they are the same image type). I agree that sometimes I wished I just had a bzImage, but the current behavior seems more robust, consistent, and is less prone to user error. Is there a reason other than aligning with what other packages do to do this? Which packages do this? -- Darren > > Signed-off-by: Christopher Larson <chris_larson@mentor.com> > --- > meta/classes/kernel.bbclass | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index a85f130..90af597 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -538,6 +538,7 @@ kernel_do_deploy() { > cd ${DEPLOYDIR} > rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin > ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin > + ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE} > > cp ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt > }
Op 17 mei 2012, om 16:46 heeft Darren Hart het volgende geschreven: > On 05/15/2012 06:25 PM, Christopher Larson wrote: >> From: Christopher Larson <chris_larson@mentor.com> >> >> It's common to provide a non-machine-suffixed link in DEPLOY_DIR_IMAGE, so >> let's be consistent and do so here as well. > > This of course means that building two machines in the same build dir > will result in overwriting the latest non-machine-suffixed link > (provided they are the same image type) Actually it doesn't. At least not on angstrom, shr and slugos: koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep DEPLOY_DIR_IMAGE conf/distro/include/angstrom.inc:DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}" The above was mentioned a few weeks ago, but it looks like no one but the distros above and Chris care about proper multimachine builds.
On 05/17/2012 07:58 AM, Koen Kooi wrote: > > Op 17 mei 2012, om 16:46 heeft Darren Hart het volgende geschreven: > >> On 05/15/2012 06:25 PM, Christopher Larson wrote: >>> From: Christopher Larson <chris_larson@mentor.com> >>> >>> It's common to provide a non-machine-suffixed link in >>> DEPLOY_DIR_IMAGE, so let's be consistent and do so here as well. >> >> This of course means that building two machines in the same build >> dir will result in overwriting the latest non-machine-suffixed >> link (provided they are the same image type) > > Actually it doesn't. At least not on angstrom, shr and slugos: > > koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep > DEPLOY_DIR_IMAGE conf/distro/include/angstrom.inc:DEPLOY_DIR_IMAGE = > "${DEPLOY_DIR}/images/${MACHINE}" That seems like a good idea to me. It would make more sense to me for that to be the default. Having a DISTRO define BUILD policy seems a bit backwards. Would anyone object to including ${MACHINE} in the deploy dir by default? > > The above was mentioned a few weeks ago, but it looks like no one but > the distros above and Chris care about proper multimachine builds. Awe, you were doing so well up until there. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Patch
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index a85f130..90af597 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -538,6 +538,7 @@ kernel_do_deploy() { cd ${DEPLOYDIR} rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin + ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE} cp ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt }