From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Burton, Ross" <ross.burton@intel.com>,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] classes: add gitupstream class
Date: Thu, 09 Mar 2017 13:03:38 +0000 [thread overview]
Message-ID: <1489064618.22968.106.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAJTo0LZeOiwCJzMdeSCkHuj9mfHBbjwCAKZkeAsbziHBaVhmMg@mail.gmail.com>
On Thu, 2017-03-09 at 12:38 +0000, Burton, Ross wrote:
>
> On 8 March 2017 at 17:25, Ross Burton <ross.burton@intel.com> wrote:
> > + d.setVar("S", "${WORKDIR}/git")
> > + d.setVar("PV", pv + "+git${SRCPV}")
> >
> I guess these are the only two lines which are git-specific. Would
> it be sensible to be VCS-agnostic and simply look at the protocol of
> the first entry in SRC_URI?
>
> So if someone had:
>
> BBCLASSEXTEND="devupstream:target"
> SRC_URI_class-devupstream = "svn://some/svn/url"
>
> You'd get:
>
> S=${WORKDIR}/svn
> PV=${PV}+svn${SRCPV}
>
> Annoyingly that breaks current behaviour as svn checkouts use the
> module name, whereas git clones just use "git" (and I can't remember
> why that is). The class could look at the SRC_URI further: for git
> set SRC_URI to WORKDIR/git, for svn set WORKDIR/{module name}. Also
> current practise is +svnr{SRCPV} not +svn, so that could either be
> special-cased again or ignored.
>
> Thoughts? I don't want something to be merged which we rewrite in a
> months' time...
I worry that making it support generic scms may make it fragile and
hard to extend if we do end up needing to do scm specific work in here
so I'm torn. Having a class per scm would also be annoying...
Cheers,
Richard
next prev parent reply other threads:[~2017-03-09 13:03 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
2017-03-09 12:30 ` Burton, Ross
2017-03-09 12:38 ` Burton, Ross
2017-03-09 13:03 ` Richard Purdie [this message]
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=1489064618.22968.106.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--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