[yocto] [meta-freescale] tmp/work-shared and sstate

[Gary Thomas]

On 2015-02-10 11:35, Gary Thomas wrote:
> On 2015-02-10 11:13, Christopher Larson wrote:
>>
>> On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <gary at mlbassoc.com <mailto:gary at mlbassoc.com>> wrote:
>>
>>     If I run a build where the kernel package is brought in via
>>     sstate, tmp/work-shared (in particular the kernel-source tree)
>>     is not populated.  This will break at least these recipes:
>>        meta-fsl-arm/recipes-__multimedia/gstreamer/gst-fsl-__plugin_4.0.2.bb <http://gst-fsl-plugin_4.0.2.bb>
>>        meta-fsl-arm/recipes-__multimedia/alsa/fsl-alsa-__plugins_1.0.25.bb <http://fsl-alsa-plugins_1.0.25.bb>
>>
>>     These programs reference the kernel includes directly for some
>>     ARM/i.MX specific headers (e.g. <linux/mxcfb.h>).  These headers
>>     are not part of the mainline kernel which is used to create the
>>     kernel headers that populates tmp/sysroots, so the build fails.
>>     Note: I'm not sure of the mechanism that lets these programs
>>     peek into the kernel build (I looked at them but nothing jumped
>>     out), but they do build find if the kernel is actually built
>>     and not just brought in by sstate.
>>
>>     Is this an error & if so, which recipe is at fault?  The FSL
>>     recipes, or the new kernel build/classes?
>>
>>
>> Per commit 46cdaf1c7bc597735d926af6a46f9483f7e57ce5 (oe-core 6a1ff0e7eacef595738f2fed086986fd622ec32a), you need to add this if you depend on the sources:
>>
>>      do_configure[depends] += "virtual/kernel:do_shared_workdir"
>> --
>
> Thanks, I'm checking now to see if this fixes the problem.
>
> One thing I noted is I added that line to the two recipes in
> question.  When I [re]built my target image with these changes
> in a tree that I had just built using only sstate, it kicked
> off a ton of tasks (~6000!), and it seems that it's now rebuilding
> everything from scratch, not just unpacking the kernel.  Once this
> finishes, I'll try another rebuild from sstate to see how that works,
> but it sure looks like it's doing a lot more than necessary.
>
> Is this to be expected?

I'm not sure why this complete rebuild happened (sadly, it took
more than 8 hours...)  When it completed, I tried another rebuild
from sstate only and things worked as expected with everything
coming in from sstate.

One concern though - the kernel package seems to have been completely
rebuilt, not just the work-shared tree being repopulated.  Is this
correct?

Thanks for the swift answer to this problem.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------