[yocto] Board specific bbappend file

[Bruce Ashfield]

On 13-12-05 11:44 AM, Stefan Roese wrote:
> On 05.12.2013 17:33, Bruce Ashfield wrote:
>>>> What exactly are you tried to change on a per-board basis ? Assuming
>>>> it is variables, you can use the standard OVERRIDES mechanism to
>>>> have a version specific bbappend, that changes variables on a per
>>>> board basis.
>>>>
>>>> i.e.
>>>>
>>>>         FOO_<machine name> = "bar"
>>>>         FOO_<another machine name> = "bar2"
>>>>
>>>> Assuming the generic recipe uses these variables appropriately, you'll
>>>> be fine.
>>>
>>> Specifically its the SRC_URI / SRC_URI_append variable (e.g. for a linux
>>> kernel and u-boot etc). And since this one is used in many recipes, I
>>> can't just put those settings in the machine conf file.
>>>
>>> Do you have any recommendations how to change this variable (per recipe)
>>> without touching the generic bb file?
>>
>> You can absolutely change the SRC_URI on a per-board basis. Just use
>> the technique that I showed above, and do it in a bbappend to your
>> linux recipe.
>>
>> i.e. something like: SRC_URI_qemux86 += "file://myfancypatch.patch"
>
> Yes, right. But this would mean doing it in a "generic" bbappend file? E.g.
>

Definitions vary. I wouldn't call that generic :)

> recipe:
> linux-xyz_3.12.bb
>
> and its "generic" append file:
> linux-xyz_3.12.bbappend
>
> And thinking about for example 20 boards, this would mean to add 20
> "SRC_URI_fooabc" defines to this bbappend file. Just shifting the
> changes from the bb file to the "common" bbappend file.

Yes that's how variable namespace and override resolution works (at
a high level).

>
> What I was looking for is more a way to do this on a one-file-per-board
> basis. Is this possible somehow?

There are plenty of things you could do, but I'd think of them more as
hacks (or maybe someone else reading has a clean suggestion that I'm
not aware of) with python, etc.

You could also have a layer per board, and each layer have a bbappend
with the boards changes, that's what layers provide already.

On a separate note, if you really are managing this many boards, with
patches, configs and separate changes you really don't want to spread
those patches into many layers, files and rcipes. Maintenance becomes
a big problem, as does patch failures and consistent configuration
management.

Cheers,

Bruce

>
> Thanks,
> Stefan
>