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
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
