[OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
Paul Eggleton
paul.eggleton at linux.intel.com
Wed May 13 11:03:29 UTC 2015
On Wednesday 13 May 2015 10:27:34 ChenQi wrote:
> On 05/13/2015 09:56 AM, Khem Raj wrote:
> >> On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen at windriver.com> wrote:
> >>
> >> On 05/13/2015 12:19 AM, Khem Raj wrote:
> >>>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen at windriver.com> wrote:
> >>>>
> >>>> - install
> >>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
> >>>> E_PKGARCH}-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-${TUN
> >>>> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` +
install
> >>>> $buildtools_path ${SDK_OUTPUT}/${SDKPATH}
> >>>
> >>> why not create a symink instead of poking using wild chars
> >>
> >> Because it's simpler.
> >
> > what happens if I touch an older installer ?
>
> Hi Khem,
>
> I make this patch to avoid installing a non-existent buildools-tarball.
> If we touch an old buildtools-tarball, the installation would still
> succeed. The touched one is installed.
> What would lead to a potential problem is the following situation.
> The user built buildtools-tarball, after one day, he modified key part
> of buildtools-tarball recipe, rebuilt it, and then he deliberately
> touched the old one, and then he built an ext SDK.
> I don't think that's a situation we need to take care of.
> But if you insist that we should, you can suggest a reasonable symlink
> name and I would make a new patch.
Honestly I don't see this is as being a problem we need to handle - who is
going to touch this file during normal usage? Builds failing under the
conditions described is a much more pressing issue at this point.
It could be that we should re-visit whether using buildtools-tarball rather
than having its contents be part of the native portion of the SDK is the right
approach. I'm not sure that we need to do that just at this moment though.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list