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
prev parent 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.