Per-machine DEPENDS

Per-machine DEPENDS

[Chris Tapp]

Is it possible to have the (R)DEPENDS list vary depending on the machine being built?

For example, I want 'this-bit' to be included for a 'machine-1' build, but not 'machine-2'.

Something like:

DEPENDS = "common-stuff"

DEPENDS_machine-1 = "${DEPENDS} this-stuff"

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Per-machine DEPENDS

[Paul Eggleton]

On Thursday 17 May 2012 21:10:10 Chris Tapp wrote:
> Is it possible to have the (R)DEPENDS list vary depending on the machine
> being built?
> 
> For example, I want 'this-bit' to be included for a 'machine-1' build, but
> not 'machine-2'.
> 
> Something like:
> 
> DEPENDS = "common-stuff"
> 
> DEPENDS_machine-1 = "${DEPENDS} this-stuff"

Yes, that will work. If the DEPENDS change implies some different configuration 
I'd recommend being explicit about it as well e.g. via EXTRA_OECONF or 
whatever is appropriate; this is particularly important for the case where the 
extra dependency is not included and the configure script for the application 
would auto-detect the presence of the additional dependency in the absence of 
an explicit configure option.

Also, ideally these machine-specific bits should live in a bbappend within the 
BSP for that machine, thus keeping the recipe itself more or less generic.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Per-machine DEPENDS

[Chris Tapp]

On 17 May 2012, at 21:27, Paul Eggleton wrote:

> On Thursday 17 May 2012 21:10:10 Chris Tapp wrote:
>> Is it possible to have the (R)DEPENDS list vary depending on the machine
>> being built?
>> 
>> For example, I want 'this-bit' to be included for a 'machine-1' build, but
>> not 'machine-2'.
>> 
>> Something like:
>> 
>> DEPENDS = "common-stuff"
>> 
>> DEPENDS_machine-1 = "${DEPENDS} this-stuff"
> 
> Yes, that will work. If the DEPENDS change implies some different configuration 
> I'd recommend being explicit about it as well e.g. via EXTRA_OECONF or 
> whatever is appropriate; this is particularly important for the case where the 
> extra dependency is not included and the configure script for the application 
> would auto-detect the presence of the additional dependency in the absence of 
> an explicit configure option.

Thanks. Is there some documentation that explains how the suffixes are build up, when they are used, etc. ?

> Also, ideally these machine-specific bits should live in a bbappend within the 
> BSP for that machine, thus keeping the recipe itself more or less generic.

Yes, that makes sense. I'll give it a go.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Per-machine DEPENDS

[Paul Eggleton]

On Thursday 17 May 2012 22:07:50 Chris Tapp wrote:
> On 17 May 2012, at 21:27, Paul Eggleton wrote:
> > On Thursday 17 May 2012 21:10:10 Chris Tapp wrote:
> >> Is it possible to have the (R)DEPENDS list vary depending on the machine
> >> being built?
> >> 
> >> For example, I want 'this-bit' to be included for a 'machine-1' build,
> >> but
> >> not 'machine-2'.
> >> 
> >> Something like:
> >> 
> >> DEPENDS = "common-stuff"
> >> 
> >> DEPENDS_machine-1 = "${DEPENDS} this-stuff"
> > 
> > Yes, that will work. If the DEPENDS change implies some different
> > configuration I'd recommend being explicit about it as well e.g. via
> > EXTRA_OECONF or whatever is appropriate; this is particularly important
> > for the case where the extra dependency is not included and the configure
> > script for the application would auto-detect the presence of the
> > additional dependency in the absence of an explicit configure option.
> 
> Thanks. Is there some documentation that explains how the suffixes are build
> up, when they are used, etc. ?

These "suffixes" are called overrides in BitBake parlance. If an override 
appears in the OVERRIDES variable then it is applied, and the OVERRIDES 
variable is built up out of the values of various other variables (including 
MACHINE, DISTRO, etc - see 'bitbake -e | grep OVERRIDES'). I'm pretty sure 
this is covered in the BitBake manual, although unfortunately that is only 
available in source format right now.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Per-machine DEPENDS

[Chris Tapp]

On 17 May 2012, at 22:22, Paul Eggleton wrote:

> On Thursday 17 May 2012 22:07:50 Chris Tapp wrote:
>> On 17 May 2012, at 21:27, Paul Eggleton wrote:
>>> On Thursday 17 May 2012 21:10:10 Chris Tapp wrote:
>>>> Is it possible to have the (R)DEPENDS list vary depending on the machine
>>>> being built?
>>>> 
>>>> For example, I want 'this-bit' to be included for a 'machine-1' build,
>>>> but
>>>> not 'machine-2'.
>>>> 
>>>> Something like:
>>>> 
>>>> DEPENDS = "common-stuff"
>>>> 
>>>> DEPENDS_machine-1 = "${DEPENDS} this-stuff"
>>> 
>>> Yes, that will work. If the DEPENDS change implies some different
>>> configuration I'd recommend being explicit about it as well e.g. via
>>> EXTRA_OECONF or whatever is appropriate; this is particularly important
>>> for the case where the extra dependency is not included and the configure
>>> script for the application would auto-detect the presence of the
>>> additional dependency in the absence of an explicit configure option.
>> 
>> Thanks. Is there some documentation that explains how the suffixes are build
>> up, when they are used, etc. ?
> 
> These "suffixes" are called overrides in BitBake parlance. If an override 
> appears in the OVERRIDES variable then it is applied, and the OVERRIDES 
> variable is built up out of the values of various other variables (including 
> MACHINE, DISTRO, etc - see 'bitbake -e | grep OVERRIDES'). I'm pretty sure 
> this is covered in the BitBake manual, although unfortunately that is only 
> available in source format right now.


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. 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"

Or would it be better to have distro-specific recipe trees and then (somehow) apply overrides to BBFILES:

BBFILES := "${BBFILES} ${LAYERDIR}/recipes*/*/*.bb \ 
            ${LAYERDIR}/recipes*/*/*.bbappend"

BBFILES<something-to-add-parts> "${LAYERDIR}/poky-7.0/*/*.bbappend"

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Per-machine DEPENDS

[Tomas Frydrych]

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.

(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

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

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Per-machine DEPENDS

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 3368 bytes --]

Why not using branches? For example meta-ivi maintains two branches: denzil
and master.
On May 23, 2012 10:03 PM, "Chris Tapp" <opensource@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
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 4270 bytes --]