On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clar...@kergoth.com> wrote:
> > 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. Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/ -- Christopher Larson
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
