<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="adM"><div class="h5"><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day <span dir="ltr"><<a href="mailto:rpjday@crashcourse.ca" target="_blank">rpjday@crashcourse.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, 29 Jan 2013, Martin Jansa wrote:<br>
<br>
</div>... snip ...<br>
<div><br>
> It would be better to change SRCREV to hash corresponding to that<br>
> tag and move tag only to comment above SRCREV. Such patch could be<br>
> applied in upstream...<br>
<br>
</div> which brings up a larger issue ... what is the *preferred* way of<br>
doing this if one was writing a style guide? i understand developers<br>
might like to set git SRCREV variables to meaningful tag names but, as<br>
i've learned, that really screws up the possibility of building with<br>
no network. as it is, quite a few recipes set SRCREV to a hash ID for<br>
*precisely* that reason and, in a short comment above (as you say),<br>
mention the tag it corresponds to.<br>
<br>
which brings me to what caused this annoyance in the first place --<br>
the meta-ti layer, which has only four recipes that use<br>
<br>
SRCREV = <tag name><br>
<br>
so it wouldn't be that hard to submit a patch to adjust those, but<br>
then there's this in<br>
meta-ti/recipes-kernel/linux/<a href="http://linux-keystone_3.6.6.bb" target="_blank">linux-keystone_3.6.6.bb</a>:<br>
<br>
# The tree tends to rebase, use literal stable tags<br>
SRCREV = "DEV.MCSDK-03.06.06.07"<br>
<br>
uh ... correct me if i'm wrong but isn't it in unspeakably bad taste<br>
to rebase commits that have already been published?<br>
<br>
in any event, can it be considered bad form to set SRCREV to git tag<br>
names? thoughts?<div><div></div></div></blockquote></div><br></div></div>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.</blockquote>
</div><br>Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/<br>-- <br>Christopher Larson</div></div>