[yocto] Per-machine DEPENDS

[Chris Tapp]

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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensource at keylevel.com
www.keylevel.com