From: Randy Witt <randy.e.witt@linux.intel.com>
To: Christopher Larson <clarson@kergoth.com>,
Chen Qi <Qi.Chen@windriver.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/3] populate_sdk_ext: install the latest buildtools-tarball
Date: Wed, 27 May 2015 14:26:41 -0700 [thread overview]
Message-ID: <55663691.30806@linux.intel.com> (raw)
In-Reply-To: <CABcZANnA4C2Y4VG4qrgEzJrU2L4e=KVt_KS0PK6DnNh+gkEkvQ@mail.gmail.com>
On 05/27/2015 11:54 AM, Christopher Larson wrote:
> On Tue, May 26, 2015 at 11:09 PM, Chen Qi <Qi.Chen@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@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.
>
>
next prev parent reply other threads:[~2015-05-27 21:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 6:09 [PATCH 0/3] Extensible SDK: 3 fixes Chen Qi
2015-05-27 6:09 ` [PATCH 1/3] populate_sdk_ext: install the latest buildtools-tarball Chen Qi
2015-05-27 18:54 ` Christopher Larson
2015-05-27 21:26 ` Randy Witt [this message]
2015-05-27 22:13 ` Christopher Larson
2015-05-27 6:09 ` [PATCH 2/3] populate_sdk_ext: consider custom configuration in local.conf Chen Qi
2015-06-04 14:11 ` Paul Eggleton
2015-06-09 6:41 ` ChenQi
2015-06-09 8:59 ` Paul Eggleton
2015-05-27 6:09 ` [PATCH 3/3] copy_buildsystem: make sure bitbake directory is copied Chen Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55663691.30806@linux.intel.com \
--to=randy.e.witt@linux.intel.com \
--cc=Qi.Chen@windriver.com \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox