All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Brian Karcz <briank@russound.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: recipe dependency on externally built binaries?
Date: Wed, 31 Jul 2013 15:26:33 +0100	[thread overview]
Message-ID: <1583397.pl1NumHCto@helios> (raw)
In-Reply-To: <7b2f59a6492f42069a9fe4820a76f7ac@HERMES.RUSSOUND.com>

On Wednesday 31 July 2013 14:04:05 Brian Karcz wrote:
> That's a better answer than I was fearing. I was starting to think that
> Yocto/Poky was only intended to build/assemble versioned or released code.

Most of the time that's the way the system operates, but we're not limited to 
it. The main purpose of the checksums is to allow you to update patches or 
configuration files referred to in SRC_URI, but it works for this case as well.

The only thing I'd advise is to take care that you have mechanisms in place 
that will allow you to easily reproduce older branches. You may already have 
taken care of this; it's just that it's easy to overlook when you point to a 
local file that is not under the control of the build system.

> We are still using Edison. I started going through the cycles of trying to
> upgrade us to Dylan a month or so ago, but ran into an assortment of issues
> regarding udev (at runtime) and some issues with do_fetch/do_unpack not
> executing on an image re-build like they do in Edison. My priority list got
> adjusted a bit, and I had to abandon that effort for a while. This
> information definitely adds a little more to the benefit column of moving
> us forward.

Right. FYI, the traditional way of working with edison and older was just to 
bump PR each time you want the recipe to rebuild.

> Are you saying that if I were to move our build system forward to danny or
> Dylan that the dependency behavior I'm looking for in these recipes would
> start to work as intended? 

Yes, that's correct. If you enable the PR server you can even have PR 
incremented automatically each time a change is made, assuming this helps i.e. 
you have package management enabled on the target.

> Would this behavior survive the use of the rm_work directive?

Yes, it should interact just fine with rm_work.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


      reply	other threads:[~2013-07-31 14:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29 19:05 recipe dependency on externally built binaries? Brian Karcz
2013-07-31  9:51 ` Paul Eggleton
2013-07-31 14:04   ` Brian Karcz
2013-07-31 14:26     ` Paul Eggleton [this message]

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=1583397.pl1NumHCto@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=briank@russound.com \
    --cc=yocto@yoctoproject.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.