Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Esben Haabendal <eha@dev.doredevelopment.dk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: poky <poky@yoctoproject.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [poky] Proposed Multilib Implementation Brainstorming
Date: Wed, 06 Apr 2011 15:21:42 +0200	[thread overview]
Message-ID: <87lizn4is9.fsf@eha.doredevelopment.dk> (raw)
In-Reply-To: <1302095185.22904.31.camel@rex> (Richard Purdie's message of "Wed, 06 Apr 2011 06:06:25 -0700")

Richard Purdie <richard.purdie@linuxfoundation.org> writes:

> 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!

The one thing that in my experience pushes most people in other
directiosn than OE is the complexity.  Unless OE made simpler, I think
it will be quite hard to reach the goal of significantly reducing the
number of build systems.

I am uncertain to what effect multilib in OE will have (positive and
negative), but it is clearly not making OE simpler.

I just kind of makes things a bit ehmm... hopeless that the requests I
(and others with similar customers) hear from companies are considered
out of line for OE evolution, whereas the requests you and others hear
can be used as valid arguments for which directions to take.

It is not that I think it will add considerable burden, but is just yet
another brick to the wall to pass for developers trying to understand
OE.

Anyways, you asked and I raised my concern.

/Esben



  reply	other threads:[~2011-04-06 13:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 11:02 Proposed Multilib Implementation Brainstorming Richard Purdie
2011-04-05 23:28 ` Jeremy Puhlman
2011-04-06 18:53   ` Richard Purdie
2011-04-06  7:08 ` Esben Haabendal
2011-04-06 12:05   ` [poky] " Richard Purdie
2011-04-06 12:16     ` Esben Haabendal
2011-04-06 13:06       ` Richard Purdie
2011-04-06 13:21         ` Esben Haabendal [this message]
2011-04-06 14:19           ` Richard Purdie
2011-04-06 16:38             ` Esben Haabendal
2011-04-06 18:01     ` Hatle, Mark
2011-04-06 20:54       ` Esben Haabendal
2011-04-06 20:55       ` Esben Haabendal
2011-04-06  7:16 ` Koen Kooi
2011-04-06  8:47 ` Frans Meulenbroeks
2011-04-06 14:29   ` Richard Purdie
2011-04-06 18:06     ` [poky] " Hatle, Mark
2011-04-06 18:25   ` Tom Rini
2011-04-07  6:10     ` Koen Kooi
2011-04-06 18:26 ` Hatle, Mark
2011-04-06 18:39   ` Tom Rini
2011-04-07 15:36 ` [poky] " Colin Walters
2011-04-07 16:10   ` Hatle, Mark
2011-04-07 16:53     ` Colin Walters
2011-04-07 17:04       ` Hatle, Mark
2011-04-07 17:10         ` Hatle, Mark
2011-04-07 17:07       ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lizn4is9.fsf@eha.doredevelopment.dk \
    --to=eha@dev.doredevelopment.dk \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@yoctoproject.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox