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

[Khem Raj]

> On May 13, 2015, at 4:03 AM, Paul Eggleton <paul.eggleton at linux.intel.com> wrote:
> 
> 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 has caused issues when we used such an approach for other artifacts
and debugging it was hard since we lost trackability with wildcads I was just sharing the experience. Ofcource
the issue at hand is always pressing thats why we are fixing it.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150513/72eb6801/attachment-0002.sig>