Re: RFC: "Virtual" native and sdk recipes

[Koen Kooi <k.kooi@student.utwente.nl>]

On 01-01-09 17:25, Richard Purdie wrote:

> Proposal Step B:
>
> To add a new variable which is a list of classes to additionally parse
> after parsing the 'base' recipe. In the above example, foo-native-1.0.bb
> would be removed and we'd instead have:
>
> foo/foo.inc:
>
> SRC_URI = "http://somwehere/${BASEPN}-${PV}.tar.bz2 \
>             file://some.patch;patch=1"
> inherit autotools
> BBCLASSEXTEND = "native"
>
> Internally bitbake would see BBCLASSEXTEND and do something like:
>
> """
> cls = value in BBCLASSEXTEND
> data.setVar('PN', pn + '-' + cls, based)
> inherit cls
> """
>

[..]

> The disadvantages:
>
> * More complexity in bitbake (but localised mainly to cache.py)
> * The .bb file is no longer one recipe but can run in different
>    flavours which will be confusing to people
> * Would require a new bitbake release and adoption of that release
>    before OE.dev can use step B functionality. Step A functionality
>    could be added without a new bitbake by putting the special function
>    in base.bbclass instead of bitbake.

If you put that code into bitbake trunk *now* and do a new release in a 
week or so people can start testing your work. OE .dev can require that 
bitbake release when the branch with BBCLASSEXTEND lands.
The important part is that bitbake has BBCLASSEXTEND in a release real 
soon :)

regards,

Koen