Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Andre McCurdy <armccurdy@gmail.com>, Ross Burton <ross.burton@intel.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] classes: add gitupstream class
Date: Wed, 08 Mar 2017 23:13:02 +0000	[thread overview]
Message-ID: <1489014782.22968.82.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAJ86T=XSzySy8kV__TbKXnMWr-2RGjGPsGjD-MxVJV_CXbnVEQ@mail.gmail.com>

On Wed, 2017-03-08 at 14:44 -0800, Andre McCurdy wrote:
> On Wed, Mar 8, 2017 at 12:54 PM, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > 
> > On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton <ross.burton@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@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


  reply	other threads:[~2017-03-08 23:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08 17:25 [PATCH] classes: add gitupstream class Ross Burton
2017-03-08 17:31 ` Mark Hatle
2017-03-08 17:36   ` Burton, Ross
2017-03-08 17:43     ` Mark Hatle
2017-03-08 17:45       ` Burton, Ross
2017-03-08 20:04         ` Mark Hatle
2017-03-08 20:54 ` Andre McCurdy
2017-03-08 22:44   ` Andre McCurdy
2017-03-08 23:13     ` Richard Purdie [this message]
2017-03-09 12:30   ` Burton, Ross
2017-03-09 12:38 ` Burton, Ross
2017-03-09 13:03   ` Richard Purdie
2017-03-09 15:02     ` Burton, Ross

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=1489014782.22968.82.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=armccurdy@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox