On Mon, Nov 16, 2009 at 01:55:48PM +0000, Richard Purdie wrote:

On Mon, 2009-11-16 at 14:43 +0100, Martin Jansa wrote:

On Mon, Nov 16, 2009 at 12:37:02PM +0000, Richard Purdie wrote:

On Mon, 2009-11-16 at 13:10 +0100, Koen Kooi wrote:
I think we will have to hold off some of the SRCPV migration until
bitbake has some kind of lock down functionality for the local build
numbers. Any volunteers to write a patch?

This could be enough?

Just putting
BB_GIT_LOCALCOUNT_FOR_SRCREV = "0"
somewhere (local.conf/distro.conf) and _count will always stay on 0
(gitr0+abc1234def)

No, we need to be able to control the version and it shouldn't be git
specific...

Cheers,

Richard

OK better version

with this you can add

LOCALCOUNT_pn-bar ?= "4"
to ie sane-srcrevs.inc

or

LOCALCOUNT ?= "4" to
recipes/foo/bar_git.bb

(btw seems like LOCALCOUNT_pn-bar has higher preferrence even if I use
"LOCALCOUNT = 4" in recipe, why?)

And it will be ignored for all distros where BB_LOCALCOUNT_OVERRIDE is
not set.

With BB_LOCALCOUNT_OVERRIDE enabled, you can use LOCALCOUNT instead of
PR bump if you just change SRCREV, for others will be LOCALCOUNT in
SRCPV incremented by default.

If BB_GIT_CLONE_FOR_SRCREV is set than LOCALCOUNT is ALWAYS set to
"git list-rev | wc -l" which could be considered also as consistent PV
scheme for multiple buildhosts.

BTW: SRCPV seems to be expanded in PV a bit sooner than SRCREV was,
which with combination with BB_GIT_CLONE_FOR_SRCREV means that all git
repositories are checked during recipe parsing (Klaus Kurzmann has a
list of git repositories used in OE recipes which are not accessible)

--
uin:136542059 jid:Martin.Jansa@...
Jansa Martin sip:jamasip@...
JaMa