RFC: nativesdk and native recipe names

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

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: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

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

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

Cheers,

Richard

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.

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.

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

Cheers,

Richard