From: pieterg <pieterg@gmx.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: AUTOREV and SRCPV
Date: Sat, 5 Jun 2010 12:36:07 +0200 [thread overview]
Message-ID: <201006051236.07938.pieterg@gmx.com> (raw)
In-Reply-To: <1275649408.23726.5.camel@mill.internal.reciva.com>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
On Friday 04 June 2010 13:03:28 Phil Blundell wrote:
> On Fri, 2010-06-04 at 10:44 +0200, pieterg wrote:
> > I'm starting to see your point. That would really allow a much nicer
> > AUTOREV implementation.
> > But in that case I'm not getting away with a simple workaround I'm
> > afraid...
>
> I think you're probably right that there is no trivial workaround, but I
> don't think it would be very hard to fix this "properly". You can do it
> one recipe at a time; there's no need for a single big bang.
It turns out not to be that hard at all.
I've created a simple gitpkv.bbclass (see attachment), and I'm able to use
it as follows, in the recipe:
inherit gitpkgv
PV = "1.0+git${SRCPV}"
PKGV = "1.0+git${GITPKGV}"
And in my distro's unstable-version.inc:
SRCREV_pn-packagename = "${AUTOREV}"
And in my distro's stable-version.inc:
SRCREV_pn-packagename = "5276f059461b6e9015e46a01b1cabfc42dfa600f"
Now I get a nice
1.0+git7348+5276f059461b6e9015e46a01b1cabfc42dfa600f
PKGV, which is the same in both stable/unstable situations, assuming
the 'stable' rev is the latest rev.
And it is of course the same on all buildservers, and doesn't depend on
what's in the cache.
And best of all, no more need for BB_LOCALCOUNT_OVERRIDE nor
BB_GIT_CLONE_FOR_SRCREV, so no more lengthy bb parse sessions.
gitpkg.bbclass could be improved.
It currently does not support SRCREV_FORMAT, instead it assumes the first
git url is to be used.
To make it obey SRCREV_FORMAT, I would have to duplicate more bitbake code.
Instead, it might be better if bb/lib/fetch/__init__.py would export helpers
to find the correct src url, in the same way bb.fetch.get_srcrev does.
That would ensure gitpkgv.bbclass would always pick the correct repository.
But for now, I'm really happy with the result.
Rgds, Pieter
[-- Attachment #2: gitpkgv.bbclass --]
[-- Type: text/plain, Size: 1210 bytes --]
# gitpkgv.bbclass provides a GITPKGV variable which is a sortable version
# with the format NN+GITHASH, to be used in PKGV, where
#
# NN equals the total number of revs up to SRCREV
# GITHASH is SRCREV's (full) hash
#
# gitpkgv.bbclass assumes the git repository has been cloned, and contains
# SRCREV. So ${GITPKGV} should never be used in PV, only in PKGV.
# It can handle SRCREV = ${AUTOREV}, as well as SRCREV = "<some fixed git hash>"
#
# use example:
#
# inherit gitpkgv
#
# PV = "1.0+git${SRCPV}"
# PKGV = "1.0+git${GITPKGV}"
GITPKGV = "${@get_git_pkgv(d)}"
def get_git_pkgv(d):
import os
import bb
urls = bb.data.getVar('SRC_URI', d, 1).split()
for url in urls:
(type, host, path, user, pswd, parm) = bb.decodeurl(bb.data.expand(url, d))
if type in ['git']:
gitsrcname = '%s%s' % (host, path.replace('/', '.'))
repodir = os.path.join(bb.data.expand('${GITDIR}', d), gitsrcname)
rev = bb.fetch.get_srcrev(d).split('+')[1]
cwd = os.getcwd()
os.chdir(repodir)
output = bb.fetch.runfetchcmd("git rev-list %s -- 2> /dev/null | wc -l" % rev, d, quiet=True)
os.chdir(cwd)
return "%s+%s" % (output.split()[0], rev)
return "0+0"
next prev parent reply other threads:[~2010-06-05 10:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 21:51 AUTOREV and SRCPV pieterg
2010-06-03 4:35 ` Martin Jansa
2010-06-03 7:15 ` pieterg
2010-06-03 7:37 ` Martin Jansa
2010-06-03 8:02 ` pieterg
2010-06-03 8:27 ` Martin Jansa
2010-06-03 8:44 ` pieterg
2010-06-03 9:22 ` pieterg
2010-06-03 8:13 ` Phil Blundell
2010-06-03 8:30 ` Martin Jansa
2010-06-03 8:37 ` Phil Blundell
2010-06-03 8:46 ` Martin Jansa
2010-06-03 8:55 ` Phil Blundell
2010-06-03 16:35 ` Phil Blundell
2010-06-04 8:24 ` pieterg
2010-06-04 8:30 ` Phil Blundell
2010-06-04 8:44 ` pieterg
2010-06-04 11:03 ` Phil Blundell
2010-06-05 10:36 ` pieterg [this message]
2010-06-06 21:00 ` Phil Blundell
2010-06-07 0:13 ` Khem Raj
2010-06-08 10:09 ` Phil Blundell
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=201006051236.07938.pieterg@gmx.com \
--to=pieterg@gmx.com \
--cc=openembedded-devel@lists.openembedded.org \
/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