Re: [PATCH v2 3/3] bitbake.conf: Set GITPKGV variable

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2015-06-09 at 10:56 +0100, Paul Eggleton wrote:
> Hi Mike,
> 
> On Tuesday 09 June 2015 10:50:55 Mike Looijmans wrote:
> > On 22-05-15 08:29, Mike Looijmans wrote:
> > > Set GITPKGV to mimic the meta-openembedded 'gitpkgv' class. This allows
> > > a recipe to simply set:
> > > PKGV="1.2+${GITPKGV}"
> > > And no longer needs to inherit gitpkgv class.
> > > ---
> > > 
> > >   conf/bitbake.conf | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> > > index a35219d..5dafd52 100644
> > > --- a/conf/bitbake.conf
> > > +++ b/conf/bitbake.conf
> > > @@ -47,3 +47,4 @@ TARGET_ARCH = "${BUILD_ARCH}"
> > > 
> > >   TMPDIR = "${TOPDIR}/tmp"
> > >   WORKDIR = "${TMPDIR}/work/${PF}"
> > >   PERSISTENT_DIR = "${TMPDIR}/cache"
> > > 
> > > +GITPKGV = "${@bb.fetch2.get_srcrev(d, 'gitpkgv_revision')}"
> > 
> > This looked okay, but when put to a practical test, I noticed that this did
> > not work at all. The GITPKGV variable is not set when building recipes,
> > resulting in the literal string ${GITPKGV} appearing in version numbers of
> > packages that try to use it.
> > 
> > It does work when I add this line to local.conf, but apparently bitbake.conf
> > never actually gets parsed?
> 
> This is because you patched the bitbake.conf in bitbake rather than OE-Core - 
> the bitbake one is really just an example and you're right, in an OE context 
> it never gets used. I think Richard skipped this one as a result, so what we'd 
> need is a patch against OE-Core's bitbake.conf to finish this off.

I just applied it to the one in bitbake since that was the one the patch
was written for.

To make this work in OE, we'd need one for OE-Core.

My only reluctance to put this into OE's bitbake.conf is that we can run
the risk of tracebacks/errors in the "bitbake -e" output. I think we
already get this for SRCREV.

Toaster is also generating errors on the autobuilder when it iterates
through the datastore and tries to expand variables like SRCREV, this
would add another such error there too :(.

Cheers,

Richard