[OE-core] RFC: nativesdk and native recipe names

[Richard Purdie]

On Wed, 2011-12-21 at 11:55 +0000, Phil Blundell wrote:
> On Wed, 2011-12-21 at 11:11 +0000, Richard Purdie wrote:
> > If we change nativesdk to become a prefix, the problem can share the
> > same code as multilib and become much more widely usable rather than the
> > current special cases. Its obviously a fairly major change in recipe
> > naming though. Would changing this be acceptable?
> 
> I wonder whether we should just stop this business of bashing PN around
> altogether and encode the native- or sdk-ness into PACKAGE_ARCH or some
> such instead.  (I guess this would need bitbake enhanced to be able to
> build a parallel dependency tree for each architecture, and a way of
> specifying the desired arch in DEPENDS, neither of which it can
> presumably do at the moment.) 

This is certainly an alternative and we already encode the data into
PACKAGE_ARCH FWIW. My gut instinct says the bitbake changes that would
be required are rather complex though.

At a high level the issue is making each variant appear unique to
bitbake so I guess you could do this if you prefixed PROVIDES and R*
variables internally to bitbake, a bit like BBCLASSEXTEND already does
with filenames.

This opens up questions like whether we'd have machine behave more like
a BBCLASSEXTEND so you could do something like:

bitbake qemuarm:core-image-sato qemumips:core-image-sato

which is certainly something people have asked before. Of course we'd
have to support stacking these:

bitbake qemux86:multilib-lib32:core-image-sato

and I'm shuddering to think of some of the corner cases.

In summary, I think its worth thinking about but its a long term change
which isn't going to be viable any time soon.

> All these transforms on PN seem rather fragile and, although changing
> the infix to be a prefix will help, it still doesn't completely
> eliminate the chance of ambiguity.

It doesn't eliminate the issue but it woiuld certainly be an
improvement...

Cheers,

Richard