> On May 13, 2015, at 4:03 AM, Paul Eggleton 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 wrote: >>>> >>>> On 05/13/2015 12:19 AM, Khem Raj wrote: >>>>>> On May 11, 2015, at 11:19 PM, Chen Qi 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