RFC: nativesdk and native recipe names

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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