Patchwork [RFC] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

oe-core does not define any machines, so it does not make sense to
add machine specific information in the oe-core u-boot recipe and
infrastructure.

Since every machine wishing to use the u-boot recipe would need to add itself to
COMPATIBLE_MACHINES, typically via a bbappend recipe, the mechanism loses any
utility it may have had and unecessarily complicates using the u-boot recipe. By
removing it, we simplify the task of adding support for new machines.

With these two variables removed from the base recipe, UBOOT_MACHINE must now be
specified in each machine config that requires u-boot. This is already the case
for UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS, so the change is minimal. For
example, a beagleboard machine config currently contains:

UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"

With this change, it must now contain:

UBOOT_MACHINE = "omap3_beagle_config"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
 meta/recipes-bsp/uboot/u-boot_git.bb |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

On Tue, 2011-05-17 at 16:00 -0700, Darren Hart wrote:
> oe-core does not define any machines, so it does not make sense to
> add machine specific information in the oe-core u-boot recipe and
> infrastructure.
> 
> Since every machine wishing to use the u-boot recipe would need to add itself to
> COMPATIBLE_MACHINES, typically via a bbappend recipe, the mechanism loses any
> utility it may have had and unecessarily complicates using the u-boot recipe. By
> removing it, we simplify the task of adding support for new machines.

NAK.

This break usability of things like "bitbake world" since all of a
sudden it will try and build u-boot in cases where it makes no sense
(qemu* machines for example).

I know it sounds strange but we do want this recipe enabled on a case by
case basis (and we have the beagleboard as a reference platform using it
which is handy). This means the default of no supported machine is
correct even if it looks odd.

Having the recipe deselect itself (raise a skip parsing event) if
UBOOT_MACHINE isn't set instead of using COMPATIBLE_MACHINE would be
acceptable though.

Cheers,

Richard

On 05/17/2011 04:15 PM, Richard Purdie wrote:
> On Tue, 2011-05-17 at 16:00 -0700, Darren Hart wrote:
>> oe-core does not define any machines, so it does not make sense to
>> add machine specific information in the oe-core u-boot recipe and
>> infrastructure.
>>
>> Since every machine wishing to use the u-boot recipe would need to add itself to
>> COMPATIBLE_MACHINES, typically via a bbappend recipe, the mechanism loses any
>> utility it may have had and unecessarily complicates using the u-boot recipe. By
>> removing it, we simplify the task of adding support for new machines.
> 
> NAK.
> 
> This break usability of things like "bitbake world" since all of a
> sudden it will try and build u-boot in cases where it makes no sense
> (qemu* machines for example).

OK, I thought there might be something like that surrounding
COMPATIBLE_MACHINE, thus the RFC.

> 
> I know it sounds strange but we do want this recipe enabled on a case by
> case basis (and we have the beagleboard as a reference platform using it
> which is handy). This means the default of no supported machine is
> correct even if it looks odd.
> 
> Having the recipe deselect itself (raise a skip parsing event) if
> UBOOT_MACHINE isn't set instead of using COMPATIBLE_MACHINE would be
> acceptable though.

That sounds promising. I'd like to avoid having to create a
u-boot_git.bbappend everytime you want to use u-boot. Is there an
example you can think of that does this? greping for "deselect" and
"skip pars" didn't yield any results.

Thanks,

On Tue, 2011-05-17 at 16:37 -0700, Darren Hart wrote:
> 
> On 05/17/2011 04:15 PM, Richard Purdie wrote:
> > On Tue, 2011-05-17 at 16:00 -0700, Darren Hart wrote:
> >> oe-core does not define any machines, so it does not make sense to
> >> add machine specific information in the oe-core u-boot recipe and
> >> infrastructure.
> >>
> >> Since every machine wishing to use the u-boot recipe would need to add itself to
> >> COMPATIBLE_MACHINES, typically via a bbappend recipe, the mechanism loses any
> >> utility it may have had and unecessarily complicates using the u-boot recipe. By
> >> removing it, we simplify the task of adding support for new machines.
> > 
> > NAK.
> > 
> > This break usability of things like "bitbake world" since all of a
> > sudden it will try and build u-boot in cases where it makes no sense
> > (qemu* machines for example).
> 
> OK, I thought there might be something like that surrounding
> COMPATIBLE_MACHINE, thus the RFC.
> 
> > 
> > I know it sounds strange but we do want this recipe enabled on a case by
> > case basis (and we have the beagleboard as a reference platform using it
> > which is handy). This means the default of no supported machine is
> > correct even if it looks odd.
> > 
> > Having the recipe deselect itself (raise a skip parsing event) if
> > UBOOT_MACHINE isn't set instead of using COMPATIBLE_MACHINE would be
> > acceptable though.
> 
> That sounds promising. I'd like to avoid having to create a
> u-boot_git.bbappend everytime you want to use u-boot. Is there an
> example you can think of that does this? greping for "deselect" and
> "skip pars" didn't yield any results.

grepping base.bbclass for COMPATIBLE_MACHINE might be more productive :)

The key piece is:

need_machine = bb.data.getVar('COMPATIBLE_MACHINE', d, 1)
if need_machine:
    import re
        this_machine = bb.data.getVar('MACHINE', d, 1)
        if this_machine and not re.match(need_machine, this_machine):
                raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)

which I think shows what I'm talking about clearly. And yes, ideally
this would have been called SkipRecipe but its from the days when we
were much more confused about terminology ;-).

Cheers,

Richard