* Re: Overriding a variable only in our layer
2011-11-23 1:24 ` Overriding a variable only in our layer Daniel Lazzari
@ 2011-11-23 2:53 ` Khem Raj
2011-11-23 8:41 ` Richard Purdie
1 sibling, 0 replies; 3+ messages in thread
From: Khem Raj @ 2011-11-23 2:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, Nov 22, 2011 at 5:24 PM, Daniel Lazzari <dlazzari@leapfrog.com> wrote:
> Hey everyone,
>
>
>
> I ran into an interesting problem today that I need some help with. I’m not
> sure if this is a bitbake issue or an oe-core one so I thought I’d try here
> first. We have our own layer that overlays on top of oe-core, meta-oe, and
> meta-angstrom. Our layer has a bunch of recipes that pull projects from our
> local SVN, including a recipe for u-boot. We have a build configuration file
> that has lines like the following:
>
>
>
> SRCREV_pn-u-boot = “563”
>
>
>
> We pull in this conf at build time using bitbake’s –R argument. Just
> recently we switched u-boot’s SRCREV from ${AUTOREV} to an actual revision
> number and bitbake started choking trying to parse recipes. It looks like it
> chokes while trying to parse oe-core’s u-boot git recipe because the SRCREV
> is meant for SVN, not GIT (even though our PREFERRED_VERSION is set up only
> to build our u-boot). Is there a way to override this SRCREV variable only
> when parsing recipes in our layer? I know I can do it directly in the
> recipe, but that loses us the advantages of having all of the SRCREVs in one
> file (which makes specific full rebuilds very easy).
On the contrary, in OE we prefer to delegate SRCREVs to recipes and pin
the versions of recipes
>
>
>
> Thanks,
>
>
>
> Dan Lazzari Jr.
>
> Firmware Engineer
>
> dlazzari@leapfrog.com
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Overriding a variable only in our layer
2011-11-23 1:24 ` Overriding a variable only in our layer Daniel Lazzari
2011-11-23 2:53 ` Khem Raj
@ 2011-11-23 8:41 ` Richard Purdie
1 sibling, 0 replies; 3+ messages in thread
From: Richard Purdie @ 2011-11-23 8:41 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-11-23 at 01:24 +0000, Daniel Lazzari wrote:
> I ran into an interesting problem today that I need some help with.
> I’m not sure if this is a bitbake issue or an oe-core one so I thought
> I’d try here first. We have our own layer that overlays on top of
> oe-core, meta-oe, and meta-angstrom. Our layer has a bunch of recipes
> that pull projects from our local SVN, including a recipe for u-boot.
> We have a build configuration file that has lines like the following:
>
> SRCREV_pn-u-boot = “563”
>
> We pull in this conf at build time using bitbake’s –R argument. Just
> recently we switched u-boot’s SRCREV from ${AUTOREV} to an actual
> revision number and bitbake started choking trying to parse recipes.
> It looks like it chokes while trying to parse oe-core’s u-boot git
> recipe because the SRCREV is meant for SVN, not GIT (even though our
> PREFERRED_VERSION is set up only to build our u-boot). Is there a way
> to override this SRCREV variable only when parsing recipes in our
> layer? I know I can do it directly in the recipe, but that loses us
> the advantages of having all of the SRCREVs in one file (which makes
> specific full rebuilds very easy).
We've not seen a conflict like that before. I'd suggest two possible
solutions off the top of my head:
a) Rename your svn recipe to something like "u-boot-svn" so its clear
which recipe the revision is meant for
b) .bbappend the .git recipe and force bitbake to ignore it (variables
like COMPATIBLE_HOST/COMPATIBLE_MACHINE/BROKEN spring to mind). I do
wonder if these mechanisms trigger early enough to stop bitbake choking.
If not, you could set SRCREV_pn-u-boot in the .bbappend to something it
won't choke on for the git recipe only. Not brilliant but should let you
maintain your existing file.
Cheers,
Richard
^ permalink raw reply [flat|nested] 3+ messages in thread