[OE-core] How to put a correct dependency with regards to gcc?

Reshetova, Elena elena.reshetova at intel.com
Tue Sep 22 11:13:59 UTC 2015


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?

Yes, I think this would work. There is already a check: 
https://github.com/01org/meta-security-isafw/blob/master/classes/isafw.bbclass#L39 
but currently it does return "True" for things like libgcc and the task fails 
since there are no actual sources.

Best Regards,
Elena.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7586 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150922/069bf585/attachment-0002.p7s>


More information about the Openembedded-core mailing list