Re: Processing extra field requested by bitbake -u in Cache

[Joshua Lock <josh@linux.intel.com>]

On Thu, 2011-04-28 at 09:22 +0800, Ke, Liping wrote:
> > Why must we change the invalidation mechanisms when having a separate
> > cache file per UI.
> Hi, Josh
> 
> Considering the following usage sequence, ui 1 -> non-ui (made changes) 2 -> ui (made changes)  3 -> non-ui (made changes) 4
> 
> If we use option 1, no cache invalidation needed.

If there are changes you'll still need to invalidate the cache.
I guess you're trying  to show something like the following?

== Option 1 (addition cache file for extra fields)
launch gui
<make changes>
launch gui (cache rebuild)
use cli
<make changes>
use cli (cache rebuild)
launch gui
use cli
launch gui
<make changes>
launch gui (cache rebuild)
use cli

=> 3 cache rebuilds

== Option 2 (per ui cache files)
launch gui
<make changes>
launch gui (cache rebuild)
use cli
<make changes>
use cli (cache rebuild)
launch gui (cache rebuild)
use cli
launch gui
<make changes>
launch gui (cache rebuild)
use cli (cache rebuild)

=> 5 cache rebuilds

However I can't imagine people switching UI's this frequently.

> 
> But if we use option 2, we need invalidate cache each time. I collect some local feedback here, they said it's unbearable. 

What's unbearable? The cache rebuilding time?

I'm still not clear why we need to invalidate the cache each time we
switch UI's. The cache invalidation test is the same: if any of the
dependencies have been modified or the file doesn't exist build the
cache, else load the available cache. If we are using a per UI cache
file we just run the invalidation tests against a different file each
time the UI is changed. Or am I missing something here?

Regards,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre