All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: poky@yoctoproject.org
Subject: Re: Proposed Multilib Implementation Brainstorming
Date: Wed, 06 Apr 2011 07:29:03 -0700	[thread overview]
Message-ID: <1302100143.22904.68.camel@rex> (raw)
In-Reply-To: <BANLkTim4ouc6ssOhfU4Dd8OfEq81MfC_gQ@mail.gmail.com>

On Wed, 2011-04-06 at 10:47 +0200, Frans Meulenbroeks wrote:
> I think most embedded systems would only use one lib. To take your
> lib/lib64 example:
> If I am developing for an embedded system I know whether it will run
> as 32 or 64 bit, so there is no need to have both.

I agree that this is the most common usecase and that remains unchanged.

> multilib has its merits when it comes to supporting multiple hardware systems.
> However as in the embedded world one is typically targeting a specific
> hardware configuration.
> (actually I don't recall having seen requests for multilib on the ML
> before, although I could have missed it).

These have been requests I've received verbally in general but you'll
see from the replies on the mailing list, Montavista is interested, Koen
is as are a number of others.

> Also I'm somewhat worried by the actual complexity this adds (to the
> build process and the recipes, and timewise probably also to the
> bootstrap process as additional packages have to be built).
> 
> Not sure if that is a desirable route forward, but if we (we as in OE
> members + developers) feel that OE should go that way, I would
> sugggest to have a way to opt-in or opt-out

Multilib will be opt-in. Things will operate just as they do today
unless you specify you want a multilib configuration.

Cheers,

Richard




WARNING: multiple messages have this Message-ID (diff)
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: poky@yoctoproject.org
Subject: Re: [OE-core] Proposed Multilib Implementation Brainstorming
Date: Wed, 06 Apr 2011 07:29:03 -0700	[thread overview]
Message-ID: <1302100143.22904.68.camel@rex> (raw)
In-Reply-To: <BANLkTim4ouc6ssOhfU4Dd8OfEq81MfC_gQ@mail.gmail.com>

On Wed, 2011-04-06 at 10:47 +0200, Frans Meulenbroeks wrote:
> I think most embedded systems would only use one lib. To take your
> lib/lib64 example:
> If I am developing for an embedded system I know whether it will run
> as 32 or 64 bit, so there is no need to have both.

I agree that this is the most common usecase and that remains unchanged.

> multilib has its merits when it comes to supporting multiple hardware systems.
> However as in the embedded world one is typically targeting a specific
> hardware configuration.
> (actually I don't recall having seen requests for multilib on the ML
> before, although I could have missed it).

These have been requests I've received verbally in general but you'll
see from the replies on the mailing list, Montavista is interested, Koen
is as are a number of others.

> Also I'm somewhat worried by the actual complexity this adds (to the
> build process and the recipes, and timewise probably also to the
> bootstrap process as additional packages have to be built).
> 
> Not sure if that is a desirable route forward, but if we (we as in OE
> members + developers) feel that OE should go that way, I would
> sugggest to have a way to opt-in or opt-out

Multilib will be opt-in. Things will operate just as they do today
unless you specify you want a multilib configuration.

Cheers,

Richard



  reply	other threads:[~2011-04-06 14:31 UTC|newest]

Thread overview: 49+ 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 18:53     ` [OE-core] " Richard Purdie
2011-04-06  7:08 ` Esben Haabendal
2011-04-06  7:08   ` [OE-core] " Esben Haabendal
2011-04-06 12:05   ` [poky] " Richard Purdie
2011-04-06 12:05     ` [OE-core] " Richard Purdie
2011-04-06 12:16     ` [poky] " Esben Haabendal
2011-04-06 12:16       ` [OE-core] " Esben Haabendal
2011-04-06 13:06       ` [poky] " Richard Purdie
2011-04-06 13:06         ` [OE-core] " Richard Purdie
2011-04-06 13:21         ` [poky] " Esben Haabendal
2011-04-06 13:21           ` [OE-core] " Esben Haabendal
2011-04-06 14:19           ` [poky] " Richard Purdie
2011-04-06 14:19             ` [OE-core] " Richard Purdie
2011-04-06 16:38             ` [poky] " Esben Haabendal
2011-04-06 16:38               ` [OE-core] " Esben Haabendal
2011-04-06 18:01     ` [poky] " Hatle, Mark
2011-04-06 18:01       ` [OE-core] " Hatle, Mark
2011-04-06 20:54       ` [poky] " Esben Haabendal
2011-04-06 20:54         ` [OE-core] " Esben Haabendal
2011-04-06 20:55       ` [poky] " Esben Haabendal
2011-04-06 20:55         ` [OE-core] " Esben Haabendal
2011-04-06  7:16 ` Koen Kooi
2011-04-06  7:16   ` [OE-core] " Koen Kooi
2011-04-06  8:47 ` Frans Meulenbroeks
2011-04-06 14:29   ` Richard Purdie [this message]
2011-04-06 14:29     ` [OE-core] " Richard Purdie
2011-04-06 18:06     ` [poky] " Hatle, Mark
2011-04-06 18:06       ` [OE-core] " Hatle, Mark
2011-04-06 18:43     ` Tom Rini
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:26   ` [OE-core] " Hatle, Mark
2011-04-06 18:39   ` Tom Rini
2011-04-07 15:36 ` [poky] " Colin Walters
2011-04-07 15:36   ` Colin Walters
2011-04-07 16:10   ` [poky] " Hatle, Mark
2011-04-07 16:10     ` Hatle, Mark
2011-04-07 16:53     ` [poky] " Colin Walters
2011-04-07 16:53       ` Colin Walters
2011-04-07 17:04       ` [poky] " Hatle, Mark
2011-04-07 17:04         ` Hatle, Mark
2011-04-07 17:10         ` [poky] " Hatle, Mark
2011-04-07 17:10           ` Hatle, Mark
2011-04-07 17:07       ` [poky] " Koen Kooi
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=1302100143.22904.68.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.