[meta-freescale] Linux kernel recipe override question

[John Weber]

On 2/25/14, 6:20 AM, Otavio Salvador wrote:
> John,
>
> On Tue, Feb 25, 2014 at 12:59 AM, John Weber <rjohnweber at gmail.com> wrote:
>> On 2/24/14, 2:27 PM, Robin Findley wrote:
>>> On 2014-02-24 12:51, John Weber wrote:
>>>> Here is a question someone might be able to quickly answer.
>>>>
>>>> I want to be able to override the SRCREV, SRCBRANCH, and the git
>>>> repository
>>> for
>>>> the kernel recipe in local.conf.  I like to do this so that I can do
>>>> local
>>>> hacking on a kernel without having to edit the recipe files themselves,
>>>> and
>>> I
>>>> find that managing local.conf is easier when I'm changing SRCREVs a lot.
>>>>
>>>> I've been able to override SRCBRANCH by doing this:
>>>>
>>>> In recipes-kernel/linux/linux-wandboard.inc:
>>>>
>>>> SRCBRANCH ??= "master"
>>>>
>>>> The default is set in recipes-kernel/linux/linux-wandboard_3.10.17.bb:
>>>>
>>>> SRCBRANCH ?= "<the-default-branch>"
>>>>
>>>> Then, in local.conf, I can override it:
>>>>
>>>> SRCBRANCH_linux-wandboard = "<my-local-hacking-branch>"
>>>>
>>>> This works fine for SRCBRANCH. If I do the same thing with SRCREV, it
>>> doesn't
>>>> seem to work.  I've done this:
>>>>
>>>> In linux-wandboard_3.10.17.bb:
>>>>
>>>> SRCREV ??= "<default big long commit id>"
>>>>
>>>> In local.conf:
>>>>
>>>> SRCREV_linux-wandboard = "<my local branch commit id>"
>>>>
>>>> I always get the checkout of the SRCREV assignment done in the recipe
>>>> file,
>>> not
>>>> the one I set in local.conf.
>>>>
>>>> Any idea why?  The only thing I can think of is that SRCREV is evaluated
>>> completely before
>>>> local.conf settings are evaluated.
>>>
>>> John, you were close.  Here's an example from my local.conf:
>>>
>>> PREFERRED_VERSION_linux-wandboard = "3.10.17"
>>> SRCBRANCH_pn-linux-wandboard = "wandboard_imx_3.10.17_1.0.0_beta_test"
>>> SRCREV_pn-linux-wandboard = "4299c87fd4d46fd786d1600c57986b1fe164138a"
>> Beautiful.  Thanks for the help.  This works.
>>
>>> You may want to double-check if your SRCBRANCH override really did work as
>>> you
>>> expected.  I think you need the "_pn-".
>> Yes. In my setup I had modified the assignment of SRCBRANCH to the weakest
>> one (??=) in the linux-wandboard.inc file and then set it using a stronger
>> one (?=) in the recipe (.bb) file, and then finally set it using the hardest
>> one (=) in the local.conf.  I certainly do not have a solid foundation in
>> these assignment operators.  :-)
> No; this is wrong.
>
> ??= is late setting operator. So basically if noone sets it (either a
> ?=) it is used. Another difference is that the last evaluated value
> for ??= is used.
>
> So:
>
> A ??= "value1"
> A ??= "value2"
>
> A is value2
>
> But
>
> A ??= "value1"
> A ?= "valuenew"
> A ??= "value2"
>
> A is valuenew
>
> ?= is weak setting; so:
>
> A ?= "value1"
> A ?= "value2"
>
> A is value1.

Thanks for going through this Otavio.  From your explanation, here is what I 
should be doing:

In the linux-wandboard.inc:

SRCBRANCH ??= "master"

In linux-wandboard_3.10.17.bb:

SRCBRANCH ??= "default release source branch"
           ^^^ this is the last evaluated ??= assignment, so it should be taken
SRCREV ?= "default release commit id"

In conf/local.conf:

SRCBRANCH_linux-wandboard = "my local testing branch"
SRCREV_linux-wandboard = "my local testing commit id"

SRCBRANCH works based on experience from trial and error that I've done in the past.
SRCREV does not work, again based on what I've tried.

I'll shoot you a patch to make it easy to test on your end.

John
>> Using this method I was able to remove those other changes, so this is all
>> good stuff.  What does the _pn- do?  In other recipes it serves as a short
>> reference for packagename, I think.
> Same here. pn- is a way to target the override to the package itself.
> The reason why this works is due BitBake code:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/__init__.py#n870
>
> But SRCREV_linux-wandboard should work in this case. I'd like to debug
> it here if you can send your working patch so we can understand why it
> did not.
>