Why not using branches? For example meta-ivi maintains two branches: denzil
and master.
On May 23, 2012 10:03 PM, "Chris Tapp" <opensou...@keylevel.com> wrote:
> Firstly, I should have said I was using the m-rpi as an example only ;-)
>
> On 23 May 2012, at 09:31, Tomas Frydrych wrote:
>
> > On 23/05/12 08:55, Chris Tapp wrote:
> >> Do overrides work with any variable? The RPi layer is using BBMASK to
> >> filter out some recipes when building against Yocto. This has to be
> >> manually added to local.conf.
> >
> > It does not have to be local.conf; if you are adding meta-raspberrypi,
> > you have to set up the layer configuration at minimum, and probably
> > other things, so you can set it up somewhere more appropriate.
> > local.conf is really just for changes when testing things, etc.
> >
> >> Would it be possible to do this
> >> automatically in the layer using an override based on the distro
> >> name/version? e.g. could something like the following be added to the
> >> layer.conf file?
> >>
> >> BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"
> >
> > I don't know if the overrides work with this variable in particular, but
> > even if they did, it is not a good idea for a layer of any kind to be
> > changing the BBMASK value, because the layer cannot make any assumptions
> > about what might or might not be appropriate to mask out.
>
> Ok. Is there some other way that the addition of a layer can be
> 'intelligent' so that it adapts itself to the build? For example, I have a
> layer that was designed to work with 4.x. It needed some minor changes to
> make it work with 5.x, some more for 6.x, etc. I would like to have a
> single meta-layer that will work with them all so that I only have to
> maintain a single version and not have branches for the different poky
> versions.
>
> I can probably do what needs to be done using BBMASK, but it would be nice
> if DISTRO and DISTRO_VERSION could be used to automate this. Would it not
> be appropriate for the layer to decide what it offers to a distro? i.e. not
> offer things it knows aren't compatible.
>
> > (Also note that BBMASK is pyton regex, so BBMASK += "
> > ${LAYERDIR}/stuff-i-dont-want" will not work, it would need, e.g., to
> > include the '|' operator)
> >
> >>
> >> Or would it be better to have distro-specific recipe trees
> >
> > Specifically to the m-rpi, there are only two problematic recipes, the
> > libav.bbappend, but you only know on the distro level whether you need
> > to mask this out or now (i.e., someone's poky-derrived distro might well
> > include libav).
> >
> > The second is the rpi-zram-service which needs systemd.
> > This recipe needs to be reworked so it produces both -systemd and -initd
> > packages, from which the distro can then pull in the appropriate one;
> > one of the packages can even be a dummy (which for poky could be
> > achieved by adding systemd.bbclass stub).
> >
> > Tomas
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> Chris Tapp
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
