[OE-core] [PATCH 1/3] populate_sdk_ext: install the latest buildtools-tarball

Randy Witt randy.e.witt at linux.intel.com
Wed May 27 21:26:41 UTC 2015

On 05/27/2015 11:54 AM, Christopher Larson wrote:
> On Tue, May 26, 2015 at 11:09 PM, Chen Qi <Qi.Chen at windriver.com> 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-standalone
>> -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.Chen at windriver.com>
> Hmm, if buildtools-tarball is required, why not just pull it in via
> dependencies and build a current one, rather than assuming/forcing the user
> to have done so themselves?

It is a dependency and will be built if it hasn't been built. But since


in buildtools-tarball.bb the filename will be different each time we try to copy 
it, unless we force buildtools-tarball to be rebuilt each time the sdk is 

${DATE} being used in DISTRO_VERSION is misleading in my opinion because 
different dates don't necessarily mean different contents. So we could change 
DISTRO_VERSION to not use date, or buildtools-tarball.bb to not use DISTRO_VERSION.


More information about the Openembedded-core mailing list