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

Christopher Larson clarson at kergoth.com
Wed May 27 22:13:37 UTC 2015


On Wed, May 27, 2015 at 2:26 PM, Randy Witt <randy.e.witt at linux.intel.com>
wrote:

> 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
>
> TOOLCHAIN_OUTPUTNAME ?=
> "${SDK_NAME}-buildtools-nativesdk-standalone-${DISTRO_VERSION}"
>
> 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 constructed.
>
> ${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.


I expect it’d be good if in this case DATE wasn’t whitelisted, so recipes
which use a DISTRO_VERSION which includes a date get rebuilt for a new day,
and if you don’t want that, you can remove DATE from DISTRO_VERSION.

Actually, it’d be interesting to try to rig some form of auto-incrementing
distro version based on distro metadata checksum changes or something.. Hmm.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150527/98371692/attachment-0002.html>


More information about the Openembedded-core mailing list