All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 24 Sep 2012 10:54:02 +0100	[thread overview]
Message-ID: <1348480442.4486.3.camel@ted> (raw)
In-Reply-To: <1348479655.31293.19.camel@phil-desktop>

On Mon, 2012-09-24 at 10:40 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 09:51 +0100, Richard Purdie wrote:
> > Wouldn't testing whether $dest already exists work just as well?
> 
> I wasn't totally confident that $dest was guaranteed never to exist in
> advance

do_populate_sysroot[cleandirs] = "${SYSROOT_DESTDIR}"

(dest is ${SYSROOT_DESTDIR})

>  (and that we'd never want to stage multiple $srcs into a single
> $dest).

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.

Cheers,

Richard

>   But yes, if both of those are true then I think testing for the
> existence of $dest would be fine.
> 
> p.
> 
> 





  reply	other threads:[~2012-09-24 10:07 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 [this message]
2012-09-24  9:59       ` Phil Blundell
2012-09-27 21:18       ` Phil Blundell
2012-09-27 21:35         ` Richard Purdie
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=1348480442.4486.3.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.