Re: [poky] Proposed Multilib Implementation Brainstorming

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

On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
> 
> > On Wed, 2011-04-06 at 09:08 +0200, Esben Haabendal wrote:
> >> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
> >> 
> >> > One of the items on our post 1.0 schedule is multilib and we need a plan
> >> > of implementation. I've been thinking about this for a while and at
> >> > least have some ideas how some of the issues can be handled.
> >> > ....
> >> > Does this make sense to everyone, are there any questions/ objections/
> >> > concerns/ things I've missed?
> >> 
> >> Which actual OE use-cases justify this kind of addition to OE?
> >
> > Several people wanting to use OECore have a requirement of multilib
> > support.
> 
> Just out of curiosity, could you come with some examples of such
> people or projects?

Well, you've seen Koen's reaction to the prospect of multilib support,
there is one example. I've given x32 as another at the start of this
thread. Its an issue I keep hearing about from companies too.

Fundamentally, multilib is one of the biggest remaining weaknesses of
the OE architecture. One of Yoctos objectives is to reduce the number of
build systems out there and to do this, we need to make one good fully
featured one. Until OE has multilib support there is a functionality
gap. I don't see any technical reason OE can't support mulitlibs and I
don't believe the complexity is high either, we just need to tweak some
things. 

I actually believe the core in OE is well suited to multilib support and
using it will show off some of the power in the OE architecture as I
think we can do it better than anyone else before!

> >> I know it is on the Yocto post 1.0 schedule, but is it actually a good
> >> thing for OE?  Maintaining OE recipes is clearly not going to get any
> >> easier with multilibs support.
> >
> > As detailed in the proposal you will see that the complexity added is
> > minimal. It requires a simple enhancement to BBCLASSEXTEND which is
> > likely desirable for other reasons too and that is the only real bitbake
> > change required. For the metadata, individual recipes remain unaffected
> > and also the core conf files are unchanged too.
> 
> I thought that all recipes (fx. library recipes) involved in a multilib
> build must have the appropriate multilib parts put in BBCLASSEXTEND, and
> after that, anybody touch that recipe is suddenly faced with having to
> take care not to break multilib builds (which most developers probably
> will not really care for).

The multilib conf files are responsible for changing BBCLASSEXTEND, I
don't want to see the need for many, if any recipe specific changes.

The recipe specific problems are likely to be limited to the likes of
hardcoded library paths and those already break things like
DISTRO="minimal" in OE.dev today.

Cheers,

Richard