* RFC: nativesdk and native recipe names
@ 2011-12-21 11:11 Richard Purdie
2011-12-21 11:37 ` Otavio Salvador
2011-12-21 11:55 ` Phil Blundell
0 siblings, 2 replies; 6+ messages in thread
From: Richard Purdie @ 2011-12-21 11:11 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: nativesdk and native recipe names
2011-12-21 11:11 RFC: nativesdk and native recipe names Richard Purdie
@ 2011-12-21 11:37 ` Otavio Salvador
2011-12-21 11:57 ` Anders Darander
2011-12-21 11:55 ` Phil Blundell
1 sibling, 1 reply; 6+ messages in thread
From: Otavio Salvador @ 2011-12-21 11:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: nativesdk and native recipe names
2011-12-21 11:11 RFC: nativesdk and native recipe names Richard Purdie
2011-12-21 11:37 ` Otavio Salvador
@ 2011-12-21 11:55 ` Phil Blundell
2011-12-21 12:58 ` Richard Purdie
1 sibling, 1 reply; 6+ messages in thread
From: Phil Blundell @ 2011-12-21 11:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: nativesdk and native recipe names
2011-12-21 11:37 ` Otavio Salvador
@ 2011-12-21 11:57 ` Anders Darander
2011-12-21 12:59 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Anders Darander @ 2011-12-21 11:57 UTC (permalink / raw)
To: openembedded-core
* 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: nativesdk and native recipe names
2011-12-21 11:55 ` Phil Blundell
@ 2011-12-21 12:58 ` Richard Purdie
0 siblings, 0 replies; 6+ messages in thread
From: Richard Purdie @ 2011-12-21 12:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: nativesdk and native recipe names
2011-12-21 11:57 ` Anders Darander
@ 2011-12-21 12:59 ` Richard Purdie
0 siblings, 0 replies; 6+ messages in thread
From: Richard Purdie @ 2011-12-21 12:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-21 13:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-21 11:11 RFC: nativesdk and native recipe names Richard Purdie
2011-12-21 11:37 ` Otavio Salvador
2011-12-21 11:57 ` Anders Darander
2011-12-21 12:59 ` Richard Purdie
2011-12-21 11:55 ` Phil Blundell
2011-12-21 12:58 ` Richard Purdie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox