RFC: nativesdk and native recipe names

RFC: nativesdk and native recipe names

[Richard Purdie]

We have a problem looming on the horizon with regard to the native and
particularly nativesdk recipe names.

We originally ran into this problem with the multilib code. The issue is
that its rather hard to automagically translate PACKAGES and
DEPENDS/RDEPENDS etc. into something the BBCLASSEXTEND classes can use
and be consistent.

To illustrate the problem, imagine a PACKAGES like foo:

foo-dev doo-dbg foo-doc foo-utils

which is built from:

${PN} ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}-utils

The class extension code changes PN and since these are constructed with
PN, they become:

foo-<class> foo-<class>-dev foo-<class>-dbg foo-<class>-doc foo-<class>-utils

Imagine you're then presented with some dependency like "foo-utils". How
do you know where to place "-<class>"?

We could write code which splits on the first dash character or a
variety of other ways but for multilibs the easiest approach was to use
a prefix instead of a suffix.

I recently proposed a patch to native.bbclass and removed some ugly
workarounds. It turns out this breaks nativesdk. There is some code in
nativesdk designed to help with this but its disabled. I tried to enable
it and hit these exact problems.

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?

Just for reference, -native is special in that PACKAGES = "" so its
easier to handle. In theory we do still have the same issue there but
R*_${PN} dependencies tend not to be problematic so we've got lucky so
far.

Cheers,

Richard

Re: RFC: nativesdk and native recipe names

[Otavio Salvador]

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

On Wed, Dec 21, 2011 at 09:11, Richard Purdie <
richard.purdie@linuxfoundation.org> 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 second this as this makes it more consistent and predictable (with the
plus of avoiding naming hacks too).

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

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

Re: RFC: nativesdk and native recipe names

[Anders Darander]

* Otavio Salvador <otavio@ossystems.com.br> [111221 12:37]:
> On Wed, Dec 21, 2011 at 09:11, Richard Purdie <
> richard.purdie@linuxfoundation.org> 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 second this as this makes it more consistent and predictable (with the plus
> of avoiding naming hacks too).

I think I'll second this as well...

So far, I haven't used the multilib-features, but just to be sure, there
is no problem with using prefixes both for multilibs and nativesdk?
(Like I said, I haven't studied the multilib code/usecases, thus it's
quite possible that this is a non-issue).

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: RFC: nativesdk and native recipe names

[Richard Purdie]

On Wed, 2011-12-21 at 12:57 +0100, Anders Darander wrote:
> * Otavio Salvador <otavio@ossystems.com.br> [111221 12:37]:
> > On Wed, Dec 21, 2011 at 09:11, Richard Purdie <
> > richard.purdie@linuxfoundation.org> 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 second this as this makes it more consistent and predictable (with the plus
> > of avoiding naming hacks too).
> 
> I think I'll second this as well...
> 
> So far, I haven't used the multilib-features, but just to be sure, there
> is no problem with using prefixes both for multilibs and nativesdk?
> (Like I said, I haven't studied the multilib code/usecases, thus it's
> quite possible that this is a non-issue).

No, assuming the namespaces are kept separate which isn't an issue as
long as you never want a multilib called "nativesdk" :)

Cheers,

Richard

Re: RFC: nativesdk and native recipe names

[Phil Blundell]

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

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.

p.

Re: 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