On Thu, Dec 16, 2010 at 19:52, Martin Jansa <martin.ja...@gmail.com> wrote: > On Thu, Dec 16, 2010 at 02:07:37PM -0200, Otavio Salvador wrote: >> Using ${GITPKGVTAG} allows for automatic versioning based on the >> repository tags. For those that doesn't want to use it, ${GITPKGV} is >> still available. > > Thanks for merging it to one bbclass. IMHO looks much better now. > Consider providing examples and warning as suggested bellow.
You're welcome. Thanks for keep commenting on it and helping with good advices. ... > # PV = "1.0+gitr${SRCPV}" # expands to something like > 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b > # PKGV = "1.0+gitr${GITPKGV}" # expands also to something like > 1.0+gitr31337+4c1c21d7dbbf93b0df336994524313dfe0d4963b added. ... > As we were discussing with otavio on #oe, I think there should be > warning, that GITPKGVTAG is really sortable only if the upstream repo > keeps consistent AND sortable tag names. > > For example tags in OE repo will fail, because only tested_2010-* tags > are sortable but this sequence: > > tested_2010-11-04 > release-2010.12-branchpoint > tested_2010-11-12 > > is not. And only way to fix it when it's shiped with non-standard tag to > targets is to bump PE :/. Yes. I fully agree that it is something the user of the class need to be aware of. > Even better solution would be to set something like GITTAGFORMAT in > recipe, to expected consistent tag scheme and if returned git describe > prefix is different then warn builder about it or even fail or ignore > that tag. I like the idea but I prefer to have this merged soon so I can started using it (for example in freerdp package) and at company. > Proposed "warning": > > # or if upstream repository is always using consistent and sortable tag > # name scheme you can get sortable version including tag name with > # GITPKGVTAG, but be aware that ie tag sequence "v1.0, v1.2, xtest, v2.0" > # will force you to increment PE to get upgradeable path to v2.0 revisions I added it as a warning on the comment. The final header is: # gitpkgv.bbclass provides a GITPKGV and GITPKGVTAG variables to be # used in PKGV, as described bellow: # # - GITPKGV 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 # # - GITPKGVTAG which is the output of 'git describe' allowing for # automatic versioning # # gitpkgv.bbclass assumes the git repository has been cloned, and # contains SRCREV. So ${GITPKGV} and ${GITPKGVTAG} should never be # used in PV, only in PKGV. It can handle SRCREV = ${AUTOREV}, as # well as SRCREV = "<some fixed git hash>". # # WARNING: if upstream repository is always using consistent and # sortable tag name scheme you can get sortable version including tag # name with ${GITPKGVTAG}, but be aware that ie tag sequence "v1.0, # v1.2, xtest, v2.0" will force you to increment PE to get upgradeable # path to v2.0 revisions # # use example: # # inherit gitpkgv # # PV = "1.0+gitr${SRCPV}" # expands to something like 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b # PKGV = "1.0+gitr${GITPKGV}" # expands also to something like 1.0+gitr31337+4c1c21d7d # # or # # inherit gitpkgv # # PV = "1.0+gitr${SRCPV}" # expands to something like 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b # PKGV = "${GITPKGVTAG}" # expands to something like 1.0-31337+g4c1c21d # if there is tag v1.0 before this revision or # ver1.0-31337+g4c1c21d if there is tag ver1.0 Does it seems good enough for pushing it? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel