On 08/18/2015 09:51 PM, Paul Eggleton wrote:
On Monday 10 August 2015 11:17:59 Chen Qi wrote:
If we do `bitbake buildtools-tarball' and then after one day do `bitbake
core-image-minimal -c populate_sdk_ext', we would meet errors like below.
| install: cannot stat
| '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/
poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standalon
e -1.8+snapshot-20150429.sh': No such file or directory
The problem is that the output name for buildtools-tarball has ${DATE} in
it. So if populate_sdk_ext task is executed but buildtools-tarball is not
rebuilt, the above error appears.
Instead of hardcoding ${DISTRO_VERSION} which consists of ${DATE} in the
install_tools() function, we should find the latest buildtools-tarball based
on the modification time and install it.
[YOCTO #7674]
Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
meta/classes/populate_sdk_ext.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass index a36bf16..b6725e0 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -169,7 +169,9 @@ install_tools() {
lnr ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath}/recipetool
${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/recipetool touch
${SDK_OUTPUT}/${SDKPATH}/.devtoolbase
- install
${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKG
ARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh
${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and install it
+ buildtools_path=`ls -t1
${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKG
ARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` + install
$buildtools_path ${SDK_OUTPUT}/${SDKPATH}
install ${SDK_DEPLOY}/${BUILD_ARCH}-nativesdk-libc.tar.bz2
${SDK_OUTPUT}/${SDKPATH} }
Hmm, it turns out there's another problem here - this assumes SDK_NAME is set
as it is in poky. Perhaps we correct that in a follow-up patch though, but
it'll be a little bit tricky as it'll need to be done by getting the actual
value of SDK_NAME as it would have been when IMAGE_BASENAME is "buildtools-
tarball".
The more I think about this though the more I wonder why we're bothering with
buildtools instead of just bundling its contents inside the native part of the
extensible SDK itself. Randy can you remind me why we did it that way?
Cheers,
Paul
Hi Paul,
I've dropped this patch from the patchset and sent out V2.
I think we can fix this buildtool problem in other patches.
Best Regards,
Chen Qi
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
