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>
Subject: Re: [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'
Date: Wed, 15 Jun 2011 12:36:22 +0100	[thread overview]
Message-ID: <1308137782.15712.415.camel@rex> (raw)
In-Reply-To: <0566033F-1AB8-4E16-A064-A3EB3A5CA143@dominion.thruhere.net>

On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote:
> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
> >> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
> > I know, but we have two choices:
> > 
> > a) Continue this spiral of confusing variable names, conflict and wacky 
> >   bugs
> > 
> > b) Come up with a plan to address it and roll it out
> > 
> > I'm favouring b), particularly since this would help several different
> > architectures with a variety of issues. If we need to better document
> > that and have a process fine, but that is not a good argument for not
> > doing it at all.
> 
> I agree on that, put previous efforts in the yocto universe were
> rushed through (like the machine-name -> machine_name change I keep
> going on about), so I have a knee jerk reaction to such things
> nowadays. For various reasons yocto and later oe-core have not been
> friendly to distros having package feeds out there. Sometimes the
> changes made things better, but they were still painfull. It seems to
> be getting better nowadays, which is good, but everyone still needs to
> be carefull. Pet peeve: missing PR bumps.

Well, I think everyone is trying to improve, trying to do better and
hopefully we are learning from any mistakes made.

> What I need for angstrom is a variable that:For 
> 
> 1) *never* changes its value

As I've mentioned several times, I think it is reasonable to allarch to
clear or otherwise invalidate such a variable. That is a very special
case though and setting it to "all" was perhaps a poor choice of value.

> 2) holds the base arch (armv7a, ppc603e, etc)

Sounds like BASE_PACKAGE_ARCH

> 3) Is set in *all* the tune include files

Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH?

Grepping the tune files in OE-Core we seem to be pretty good about this
right now.

> 4) must be set to complete parsing when MACHINE is set

I suspect this doesn't give as much value as you'd think but I'm
indifferent.

> I don't care if it's in overrides by default or not since that's easy
> enough to do in distro configs.

Is this a decision the machine/tune files should make or the distro
though?

Cheers,

Richard




  reply	other threads:[~2011-06-15 11:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 21:13 [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all' Khem Raj
2011-06-14 21:18 ` Koen Kooi
2011-06-14 21:24 ` Richard Purdie
2011-06-14 21:32   ` Khem Raj
2011-06-14 21:33     ` Koen Kooi
2011-06-14 21:39       ` Khem Raj
2011-06-14 21:32   ` Koen Kooi
2011-06-14 21:40     ` Khem Raj
2011-06-14 21:44       ` Koen Kooi
2011-06-14 23:12         ` Khem Raj
2011-06-15  7:00           ` Koen Kooi
2011-06-15 10:16             ` Richard Purdie
2011-06-15 10:18               ` Koen Kooi
2011-06-15 10:23                 ` Richard Purdie
2011-06-15 15:28                   ` Khem Raj
2011-06-15 10:07     ` Richard Purdie
2011-06-15 10:15       ` Koen Kooi
2011-06-15 10:22         ` Richard Purdie
2011-06-15 10:37           ` Koen Kooi
2011-06-15 11:36             ` Richard Purdie [this message]
2011-06-15 11:52               ` Koen Kooi
2011-06-15 15:29                 ` Mark Hatle
2011-06-15  8:56   ` Koen Kooi
2011-06-15  9:33     ` Richard Purdie

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=1308137782.15712.415.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.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.