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
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
