All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Seebach <peter.seebach@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Toolchain library whitelisting: A first pass (preliminary patch/RFC)
Date: Thu, 26 Apr 2012 17:42:55 -0500	[thread overview]
Message-ID: <20120426174255.6739e594@wrlaptop> (raw)
In-Reply-To: <4F99C5C5.8090901@windriver.com>

On Thu, 26 Apr 2012 17:01:41 -0500
Mark Hatle <mark.hatle@windriver.com> wrote:

> split does a whitespace based split automatically, I'm used to
> seeing .split() everywhere.  (I won't comment on the other similar
> split items)

Okay.
 
> > +    validities = data.getVarFlags('TUNEVALID') or ""
 
> "validities"?  that a new word?  ;)

Pretty much.  I was trying to think of a name for "the set of valid
things".  :)

> Change the above to:
>      multilibs = data.getVar("MULTILIBS", True)
>      if multilibs:

If someone has done:

MULTILIBS = ""

this then ends up being confused because pairs[0] of the single
returned item is still "", and that's not valid.
 
> > +		if pairs[1] == 'lib':
> > +		    tune_error_set.append("The multilib 'lib' was
> > specified, but that doesn't work. You need lib32 or lib64.")
 
> I'm surprised, why doesn't 'lib' work?  I was under the impression
> the naming was completely arbitrary.

I am surprised too, but if I use that name, I get a cryptic parse
error from libxcb's recipe which I couldn't understand.
 
> Also we can definitely have more then just lib32 or lib64.  We
> already often use libx32 in testing the x32 layer.

Okay.  I can improve the message, for sure.
 
> If the tune isn't defined, then the multilib configuration is
> invalid.  I thought we already had a check for that somewhere else..
> but if not.. it wouldn't be a bad idea to mention that here for the
> user.

That probably wants to be tested too.

> I wonder if this is an error or a warning.. I suspect it would be
> unintentional, but I'm not sure it's a failure?

I'm not totally sure.  I blamed that for my problem where I kept
getting a TUNE_ARCH of "x86_64x86_64" or "i586i586", but it turned out
to be a red herring.

I could change that to a warning.

> Your whitespace usage looks different.. perhaps that is just my
> mailer.

I almost certainly have tabs.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.



  reply	other threads:[~2012-04-26 22:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  1:38 Toolchain library whitelisting: A first pass Peter Seebach
2012-04-26 21:08 ` Toolchain library whitelisting: A first pass (preliminary patch/RFC) Peter Seebach
2012-04-26 22:01   ` Mark Hatle
2012-04-26 22:42     ` Peter Seebach [this message]
2012-04-27  5:15       ` Chris Larson

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=20120426174255.6739e594@wrlaptop \
    --to=peter.seebach@windriver.com \
    --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.