On Wed, 30 Jan 2013, Chris Larson wrote:
> On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day <rpj...@crashcourse.ca>
> wrote:
> On Wed, 30 Jan 2013, Chris Larson wrote:
>
> > 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.
>
> i'm not in the least embarrassed to admit i didn't even know that
> variable existed. and, yes, that pretty much solves the problem.
>
> Keep in mind, though, it stores it in the persist_data cache, which
> by default lives inside of TMPDIR. So if you're going to set it to
> cache, best move the persist dir outside of tmpdir, or just make
> sure you keep the TMPDIR around.
which is why, while these are useful features, they require
foresight and planning, and still won't do me any good if i neglect to
take advantage of them and suddenly, without warning, find myself
lacking net access.
it's definitely frustrating to know i have all the necessary
tarballs for a build, but a fresh build will fail because some recipes
can't be parsed, especially when (i hope i'm getting this right) some
of those recipes won't even be involved in the construction of the
final image (*all* available recipes are parsed, correct? not just
the ones that will be used to build the image.)
so, from my perspective, it would still be good coding style to
avoid using tags as SRCREV values, period.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
