Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <philb@gnu.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] kexec-tools: admit mips as a COMPATIBLE_HOST
Date: Mon, 24 Sep 2012 21:51:18 +0100	[thread overview]
Message-ID: <1348519878.8662.14.camel@ted> (raw)
In-Reply-To: <1348518219.4444.262.camel@x121e.pbcl.net>

On Mon, 2012-09-24 at 21:23 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 11:28 -0700, Khem Raj wrote:
> > On Mon, Sep 24, 2012 at 4:49 AM, Phil Blundell <philb@gnu.org> wrote:
> > >
> > > -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
> > > +COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'
> > 
> > I wonder if this expression should be removed completely now that mips is added
> > we dont have any supported arch left.
> 
> There are at least a few Linux architectures not in that list: alpha and
> sparc are the obvious two, but there are a few more obscure ones as
> well.  I don't think alpha has ever really been supported in oe-core,
> but there are at least some sparc bits in there and, of course, it is
> possible for an external layer to add support for new architectures.
> Plus, of course, there is the OS side: if you were targetting mingw32
> for example then kexec-tools would clearly not work.
> 
> However, all that said, I tend to agree that the COMPATIBLE_HOST check
> isn't buying much in this recipe.  The original intent of
> COMPATIBLE_MACHINE (and later COMPATIBLE_HOST) was to prevent bitbake
> from selecting inappropriate providers to satisfy a virtual dependency:
> in particular, the idea was that it would stop you picking up a kernel
> recipe for some completely unrelated hardware.  In the case of
> kexec-tools there are no alternative providers available and it isn't
> totally obvious that having the recipe skip itself on a host that it
> thinks is "unsupported" is really any better than letting it try and
> fail to build.  So I would be happy to see that check removed.

Going back in time, kexec only worked on a handful of platforms so the
check made sense. Now mips support is there, it can probably be removed.

Part of the reasoning this is here is to make world builds useful as a
test that everything builds.

Cheers,

Richard




  reply	other threads:[~2012-09-24 21:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-24 11:49 [PATCH] kexec-tools: admit mips as a COMPATIBLE_HOST Phil Blundell
2012-09-24 18:28 ` Khem Raj
2012-09-24 19:10   ` McClintock Matthew-B29882
2012-09-24 19:15     ` Khem Raj
2012-09-24 20:23   ` Phil Blundell
2012-09-24 20:51     ` Richard Purdie [this message]
2012-09-27 15:55 ` Saul Wold

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=1348519878.8662.14.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.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