From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: poky@yoctoproject.org
Subject: Re: New warning
Date: Fri, 22 Jun 2012 10:44:12 +0100 [thread overview]
Message-ID: <3380572.szjuG0GuWa@helios> (raw)
In-Reply-To: <4FE253E8.7090901@mlbassoc.com>
On Wednesday 20 June 2012 16:51:20 Gary Thomas wrote:
> On 2012-06-20 15:55, Khem Raj wrote:
> > On Wed, Jun 20, 2012 at 12:12 PM, Gary Thomas<gary@mlbassoc.com> wrote:
> >> This happens when I have two intertwined layers - I have a recipe in
> >> layer1
> >> which references a file satisfied only by layer2.
> >
> > why not move the reference from layer1 to layer2 as well ?
>
> Layer1 holds the recipe and I find it more informative to have the
> reference there - that way the .bbappends in layer2 _must_ define
> it and the dependency is obvious since the recipe will fail without
> this file being specified.
>
> My use case is layer1 has a generic kernel recipe and layer2 (BSP)
> has a platform specific patch for that kernel. I have other use
> cases, but this is indicative of how I view the layering.
Well, that's not unreasonable I suppose. However I've just tested a trivial
example of cross-layer file references here and it does not produce a warning.
In any case, the code that does the checksums uses the same code as do_fetch
when it locates the files, so I'm a bit puzzled as to how it would not be able
to find the file in the first instance and it would when it came to fetch time.
FWIW, Andrea and I figured out that his reported case was caused by some
recipes that only provided a file for specific machines which did not include
the current MACHINE, but the recipes were not marked with COMPATIBLE_MACHINE,
so the warning there was legitimate. Gary, is it possible something similar is
happening for your layer structure? If not, can you provide some more
information that might help me reproduce the warning?
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-06-22 9:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 19:12 New warning Gary Thomas
2012-06-20 21:55 ` Khem Raj
2012-06-20 22:51 ` Gary Thomas
2012-06-21 8:26 ` Andrea Adami
2012-06-22 9:44 ` Paul Eggleton [this message]
2012-06-22 11:49 ` Gary Thomas
2012-06-22 12:35 ` Tomas Frydrych
2012-06-22 13:01 ` Paul Eggleton
2012-06-22 13:05 ` Paul Eggleton
2012-06-22 13:31 ` Gary Thomas
2012-06-22 14:25 ` Khem Raj
-- strict thread matches above, loose matches on Subject: below --
2012-10-02 15:34 Gary Thomas
2012-10-02 15:43 ` Richard Purdie
2012-10-03 6:22 ` Khem Raj
2016-06-08 2:55 Gary Thomas
2016-06-08 3:20 ` Christopher Larson
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=3380572.szjuG0GuWa@helios \
--to=paul.eggleton@linux.intel.com \
--cc=poky@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.