On Thu, Dec 05, 2013 at 11:51:18AM -0500, Bruce Ashfield wrote: > 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.
Overrides should be used even in cases with separate layer for each board. Documentation was improved lately about this problem: http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#best-practices-to-follow-when-creating-layers > 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 -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
