[OE-core] [PATCH] classes: add gitupstream class

Richard Purdie richard.purdie at linuxfoundation.org
Wed Mar 8 23:13:02 UTC 2017


On Wed, 2017-03-08 at 14:44 -0800, Andre McCurdy wrote:
> On Wed, Mar 8, 2017 at 12:54 PM, Andre McCurdy <armccurdy at gmail.com>
> wrote:
> > 
> > On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton <ross.burton at intel.com>
> > wrote:
> > > 
> > > This class lets you use BBCLASSEXTEND to add a variant of the
> > > recipe that
> > > fetches from git instead of a tarball.
> > Looks good. This approach could perhaps also cover git -vs-
> > externalsrc variants of a recipe, which seems to be a big topic for
> > a
> > lot of users.
> > 
> > > 
> > > For example:
> > > 
> > >  BBCLASSEXTEND = "gitupstream:target"
> > >  SRC_URI_class-gitupstream = "git://git.example.com/example"
> > >  SRCREV_class-gitupstream = "abcd1234"
> > > 
> > > This variant will have DEFAULT_PREFERENCE set to -1 so it needs
> > > to be selected
> > > to be used
> > So if I want to select the gitupstream variant, what should I set
> > PREFERRED_VERSION to?
> > 
> > > 
> > > , and any git-specific tweaks can be done with the class-
> > > gitupstream
> > > override, for example:
> > > 
> > >  DEPENDS_append_class-gitupstream = " gperf-native"
> > > 
> > >  do_configure_prepend_class-gitupstream() {
> > >     touch ${S}/README
> > >  }
> > > 
> > > It currently only supports creating a git variant of the target
> > > recipe, not
> > > native or nativesdk.  The BBCLASSEXTEND syntax
> > > (gitupstream:target) was chosen
> > > so that support for native and nativesdk can be added at a later
> > > date.
> > > 
> > > [ YOCTO #10215 ]
> > > 
> > > Signed-off-by: Ross Burton <ross.burton at intel.com>
> > > ---
> > >  meta/classes/gitupstream.bbclass | 25 +++++++++++++++++++++++++
> > >  1 file changed, 25 insertions(+)
> > >  create mode 100644 meta/classes/gitupstream.bbclass
> > > 
> > > diff --git a/meta/classes/gitupstream.bbclass
> > > b/meta/classes/gitupstream.bbclass
> > > new file mode 100644
> > > index 0000000..405283d
> > > --- /dev/null
> > > +++ b/meta/classes/gitupstream.bbclass
> > > @@ -0,0 +1,25 @@
> > > +CLASSOVERRIDE = "class-gitupstream"
> > > +
> > > +# TODO doesn't let you gitupstream a native recipe yet
> > > +
> > > +python gitupstream_virtclass_handler () {
> > > +    # Do nothing if this is inherited, as it's for BBCLASSEXTEND
> > > +    if "gitupstream" not in (e.data.getVar('BBCLASSEXTEND',
> > > True) or ""):
> > What's the significance of e.data.getVar() here -vs- d.getVar()
> > below?
> To answer my own question, this seems to be covered in the bitbake
> user manual:
> 
> "The global datastore is available as "d". In legacy code, you might
> see "e.data" used to get the datastore. However, realize that
> "e.data"
> is deprecated and you should use "d" going forward."
> 
> http://www.yoctoproject.org/docs/2.2.1/bitbake-user-manual/bitbake-us
> er-manual.html#events

Well found, I was about to reply mentioning this. I did help Scott
update that piece of the manual recently! :)

Cheers,

Richard



More information about the Openembedded-core mailing list