From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: How to put a correct dependency with regards to gcc?
Date: Tue, 22 Sep 2015 12:09:33 +0100 [thread overview]
Message-ID: <1442920173.12435.259.camel@linuxfoundation.org> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B419973E6@IRSMSX102.ger.corp.intel.com>
On Tue, 2015-09-22 at 11:03 +0000, Reshetova, Elena wrote:
> > The idea is quite simple. Rather than having a copy of the gcc source for
> > each recipe variant
> > (-cross-initial, -cross, -crosssdk-initial, -crosssdk, -cross-canadian etc.)
> > we have a single copy of the source.
>
> >We tried an older shared stamp scheme which was fragile and prone to weird
> >failures. Instead we created the gcc-source recipe which is responsible for
> >the fetch/unpack/patch/preconfigure and then each recipe can work off the
> >shared source (and has >a dependency on gcc-source).
>
> Thank you Richard for explaining this! It helps greatly!
>
> >For Elena's use case, I therefore think it might be better to analyse the
> >shared source once and not in the case of each recipe (e.g. if SRC_URI is
> >empty).
>
> I am really not sure how to do it apart from hardcoding a check inside the
> class that if the recipe happens to be gcc related, run the analysis only once
> for gcc-source and do not run it for other related packages.
> My task is currently run for every recipe uniformly and it would be not that
> elegant to have this hardcoding part. Is there a better way of handling it?
You could test if SRC_URI is empty in your code?
Then all we'd need to do is ensure that SRC_URI was empty for the gcc
recipes except for gcc-source?
Cheers,
Richard
next prev parent reply other threads:[~2015-09-22 11:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 17:03 How to put a correct dependency with regards to gcc? Reshetova, Elena
2015-09-09 2:45 ` Randy MacLeod
2015-09-09 7:05 ` Patrick Ohly
2015-09-09 16:13 ` Reshetova, Elena
2015-09-09 16:09 ` Reshetova, Elena
2015-09-14 17:55 ` Randy MacLeod
2015-09-14 18:06 ` Reshetova, Elena
2015-09-16 2:37 ` Randy MacLeod
2015-09-16 16:52 ` Richard Purdie
2015-09-22 11:03 ` Reshetova, Elena
2015-09-22 11:09 ` Richard Purdie [this message]
2015-09-22 11:13 ` Reshetova, Elena
2015-09-16 16:43 ` Richard Purdie
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=1442920173.12435.259.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=elena.reshetova@intel.com \
--cc=openembedded-core@lists.openembedded.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.