On Wed, Jan 30, 2013 at 1:49 PM, Harvey Chapman <hchapman-oec...@3gfp.com>wrote:
> On Jan 30, 2013, at 3:34 PM, Chris Larson <clar...@kergoth.com> wrote: > > On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clar...@kergoth.com> 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. > > > Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/ > > > So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache > because the former implies the latter? > The latter only works if you've already done a build in that tmpdir and therefore got the cache prepopulated. So no, it should only be enabled explicitly, indicating the user has at least considered the implications. -- Christopher Larson
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
