[OE-core] SDK extract errors on master

[Jack Mitchell]

On 06/07/15 16:56, Jack Mitchell wrote:
> 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,
>

Turns out it's one of the magic variables that requires an _append 
rather than just a +=.

The example above turns out to be from my tests using _append and I 
didn't realise it was different with just a plain +=.

To conclude, TOOLCHAIN_HOST_TASK += "nativesdk-package" will overwrite 
TOOLCHAIN_HOST_TASK to just hold nativesdk-package, as such 
nativesdk-packagegroup-sdk-host and 
packagegroup-cross-canadian-diffusion won't be present anymore which 
makes a whole lot of sense now. Using append, like so:

TOOLCHAIN_HOST_TASK_append += "nativesdk-fastboot"

Will give you the whole list and result in:

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

Which is correct. Sorry for the noise; but just a heads up that I now 
feel strongly that this should be in the Yocto Docs somewhere, there is 
no mention of extending the SDK at all from what I could see and current 
examples found online specify just a plain += is fine to use, which it 
isn't.