On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day <rpj...@crashcourse.ca>wrote:
> On Tue, 29 Jan 2013, Martin Jansa wrote: > > ... snip ... > > > It would be better to change SRCREV to hash corresponding to that > > tag and move tag only to comment above SRCREV. Such patch could be > > applied in upstream... > > which brings up a larger issue ... what is the *preferred* way of > doing this if one was writing a style guide? i understand developers > might like to set git SRCREV variables to meaningful tag names but, as > i've learned, that really screws up the possibility of building with > no network. as it is, quite a few recipes set SRCREV to a hash ID for > *precisely* that reason and, in a short comment above (as you say), > mention the tag it corresponds to. > > which brings me to what caused this annoyance in the first place -- > the meta-ti layer, which has only four recipes that use > > SRCREV = <tag name> > > so it wouldn't be that hard to submit a patch to adjust those, but > then there's this in > meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb: > > # The tree tends to rebase, use literal stable tags > SRCREV = "DEV.MCSDK-03.06.06.07" > > uh ... correct me if i'm wrong but isn't it in unspeakably bad taste > to rebase commits that have already been published? > > in any event, can it be considered bad form to set SRCREV to git tag > names? thoughts? > It's worth bringing up the SRCREV_POLICY variable, which lets you control how bitbake handles caching of srcrevs. By default, it figures it needs to get the mapping every time (value == clear, or unset), which can make sense in certain cases. But you can tell it to go ahead and use the values it has cached from a previous run, as well (value == cache). This can be useful if you know you're moving into an offline state and want to prepare for it above and beyond the -c fetchall. -- Christopher Larson
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
