Re: SDK extract errors on master

[Jack Mitchell <ml@communistcode.co.uk>]

On 06/07/15 13:30, Jack Mitchell wrote:
> On 06/07/15 12:35, Jack Mitchell wrote:
>> On 03/07/15 15:56, Jack Mitchell wrote:
>>> Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and 
>>> when I tried to install it I got the following error:
>>>
>>> Setting it up...ls: cannot access 
>>> /home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: 
>>> No such file or directory
>>>
>>> I have been messing about with the SDK install path and at one point 
>>> it did spew out a load of files installed vs shipped warnings I 
>>> assume due to a change of path and it getting upset about it, but 
>>> since then I deleted the tmp directory and rebuilt a new SDK without 
>>> warnings. However, both acted in the same way.
>>>
>>> The SDK then sits without installing, seemingly stuck on: grep 
>>> OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
>>> (non-existant) nvironment file.
>>>
>>> Any clues? Is this broken for anyone else?
>>>
>>> Cheers,
>>> Jack.
>>
>> Ok, I figured out how I broke it; I used a relative path in SDKPATH. 
>> i.e.
>>
>> SDKPATH=/path/to/sdk/../rel-sdk
>>
>> So, first off; should this be supported? Secondly, the use-case I was 
>> trying to get at was to position an SDK relative to the build dir, i.e.
>>
>> SDKPATH=${TOPDIR}/../sdk
>>
>> Is there a better way to do this. I guess this problem could be 
>> solved somewhere in an SDK class by changing the relative path to an 
>> absolute path. Ideas?
>>
>> Cheers,
>> Jack.
>
> I found an ugly work-around but it would be nice for this to be 
> supported in the future, or at least error on a relative path.
>
> SDKPATH := "${@os.path.abspath(d.getVar('TOPDIR', 
> True)+"/../sdk/"+d.getVar('SDK_VERSION', 
> True)+"/"+d.getVar('SDK_ARCH', True))}"
>
> Cheers,

The saga continues... so, using a relative path is what causes bitbake 
to spew the 'installed vs shipped' warnings; which I thought were the 
root cause of the SDK failing to install, but apparently not. I'm 
appending a custom recipe like this:

TOOLCHAIN_HOST_TASK += "nativesdk-fastboot"

Which seems to be the root cause of the SDK failing to install. I have 
grepped the output of bitbake -e image -c populate_sdk and I get:

TOOLCHAIN_HOST_TASK="nativesdk-packagegroup-sdk-host 
packagegroup-cross-canadian-diffusion nativesdk-fastboot"

Which looks perfectly reasonable to me; the fastboot recipe also builds 
without issue and the resulting package looks sane. So, why is this 
breaking the SDK and causing other packages not to be installed, it 
looks specifically like it nullifies the 
packagegroup-cross-canadian-diffusion as that is what brings in 
meta-environment and as such environment-setup-* which is what is 
claimed to be missing on SDK extract.

I'm totally out of my depth now as on the surface everything looks OK. 
Any input would be much appreciated.

Cheers,