From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <philb@gnu.org>
Cc: oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] staging: Avoid staging the same binaries again and again
Date: Thu, 27 Sep 2012 22:35:54 +0100 [thread overview]
Message-ID: <1348781754.15753.21.camel@ted> (raw)
In-Reply-To: <1348780727.4422.12.camel@x121e.pbcl.net>
On Thu, 2012-09-27 at 22:18 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote:
> > sysroot_stage_* are symmetrical so I can't imagine this happening.
> >
> > The main worry would be something happening before sysroot_stage_all.
> > SYSROOT_PREPROCESS_FUNCS happen afterwards so there is at least a hook
> > used in most cases that would avoid the issue.
> >
> > I'm torn whether its better to be simple or less fragile in this case.
> > Or simply do some tests (if ${bindir} != ${sbindir}) and so on.
>
> I'm not quite sure what the conclusion was from this previous
> discussion. Did you want me to redo the patch to work in some other
> way?
The release is now at -rc2 and this patch hasn't reached the threshold
of things I'm willing to take. I've tried to at least get some of the
patches you're posted in but I wish we'd had them a couple of weeks
ago :/.
I also wish we could find some neater/simpler way of doing this since
I'm not a fan of "obscuring" the code more than we have to. I'm not
coming up with any great ways of doing it though.
Cheers,
Richard
next prev parent reply other threads:[~2012-09-27 21:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 6:26 [PATCH] staging: Avoid staging the same binaries again and again Phil Blundell
2012-09-24 8:51 ` Richard Purdie
2012-09-24 9:40 ` Phil Blundell
2012-09-24 9:54 ` Richard Purdie
2012-09-24 9:59 ` Phil Blundell
2012-09-27 21:18 ` Phil Blundell
2012-09-27 21:35 ` Richard Purdie [this message]
2012-09-28 10:43 ` Phil Blundell
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=1348781754.15753.21.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 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.