From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] sanity.bbclass: Implement initial toolchain sanity checks
Date: Tue, 01 May 2012 11:21:14 +0100 [thread overview]
Message-ID: <1335867674.7415.76.camel@ted> (raw)
In-Reply-To: <20120430154823.3a4ea3ee@wrlaptop>
On Mon, 2012-04-30 at 15:48 -0500, Peter Seebach wrote:
> On Mon, 30 Apr 2012 15:42:44 -0500
> Mark Hatle <mark.hatle@windriver.com> wrote:
>
> > Is the above debugging? (I suspect it is) I suggest the following...
>
> Actually, that one's intentional. I originally did it for debugging,
> but I thought it was super convenient to actually get a list of the CPU
> feature set bitbake thought it was using. We can't tell you whether
> you picked the right features, but we can tell you what they are.
>
> So for instance, with a qemux86 and a core2 lib32:
>
> NOTE: Sanity-checking tuning 'x86-64' (default) features:
> NOTE: checking for conflicts: m64
> NOTE: checking for conflicts with: m32
> NOTE: m64: IA32e (x86_64) ELF64 standard ABI
> NOTE: Sanity-checking tuning 'core2' (lib32) features:
> NOTE: m32: IA32 ELF32 standard ABI
> NOTE: core2: Enable core2 specific processor optimizations
>
> I found this really handy, and left it there on purpose. I could take
> it out, and/or move it to somewhere else, but I really do like having
> that information appear.
I'd change these to debug messages. Users don't need this on the console
on every run. There is already a summary of the active tune options
displayed in the build configuration banner if I remember correctly.
Cheers,
Richard
next prev parent reply other threads:[~2012-05-01 10:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 20:33 [v3] [PATCH 0/2] toolchain sanity checks, revised Peter Seebach
2012-04-30 20:33 ` [PATCH 1/2] tune-sh4.inc: Fix spelling of big-endian feature set Peter Seebach
2012-04-30 20:33 ` [PATCH 2/2] sanity.bbclass: Implement initial toolchain sanity checks Peter Seebach
2012-04-30 20:42 ` Mark Hatle
2012-04-30 20:48 ` Peter Seebach
2012-05-01 10:21 ` Richard Purdie [this message]
2012-05-01 10:25 ` Koen Kooi
2012-05-01 15:56 ` Peter Seebach
2012-05-01 10:47 ` Richard Purdie
2012-05-01 16:23 ` Peter Seebach
2012-05-01 20:17 ` Richard Purdie
2012-05-02 1:32 ` Peter Seebach
-- strict thread matches above, loose matches on Subject: below --
2012-05-01 16:42 [PATCH 0/2] sanity.bblass: Initial " Peter Seebach
2012-05-01 16:42 ` [PATCH 2/2] sanity.bbclass: Implement initial " Peter Seebach
2012-04-27 23:51 [PATCH 0/2] sanity.bbclass: Toolchain " Peter Seebach
2012-04-27 23:51 ` [PATCH 2/2] sanity.bbclass: Implement initial toolchain " Peter Seebach
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=1335867674.7415.76.camel@ted \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox