[poky] Processing extra field requested by bitbake -u in Cache

[Ke, Liping]

> 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.

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

if we want to reduce the unnecessary invalidation, we need very careful tricky mechanism,
such as, could it be possible that when ui->no-ui, we don't' invalidation cache when the mode switching? It's not a two step state machine,
but more steps?

And also, yes extra 6 M files are the disk is not a big problem. But actually the extra three fields are not a big burden in memory, 
it's only about size(fields of the 3) * file_no (<1000)? So the extra 6M vs extra three fields in memory is a dilemma from my me plus the extra invalidation.
That's why I feel RP's suggestion is reasonable at that time?

I am still in a dilemma...

Thanks indeed for your idea!
criping



> 
> My thought is that we'll have a cache file name which encodes the UI and
> then run the usual invalidation tests against that cache.
> 
> Say that the UI name is known by the cache and stored in variable
> currentui we can achieve this by:
> 
> -        self.cachefile = os.path.join(self.cachedir, "bb_cache.dat")
> +        self.cachefile = os.path.join(self.cachedir, "bb_cache_%s.dat"
> % currentui)
> 
> Also, surely we *do* need alter the cache invalidation mechanisms for
> multiple files, at least insofar as we must test more than one cache
> file some times.
> 
> >
> > 2. Have two big cache files, one is for ui mode, one is for non-ui mode
> >   Advantage: Code change will be a little smaller. When loading, if it's non-ui
> mode, load smaller cache file. Otherwise, load bigger cache file.
> >   Disadvantage: 1) Cache invalidation mechanism (timestamp) is broken.
> When mode switching, we need to invalidate all caches, reparsing, reloading
> time 30s.
> >               s) disk file size is bigger. 2*original_size (2*6M)
> 
> I'm not sure that 6MB disk overhead is worth the code complexity
> increase by having multiple cache files stitched together.
> 
> I am definitely keen to hear others opinions here.
> 
> Cheers,
> Joshua
> --
> Joshua Lock
>         Yocto Build System Monkey
>         Intel Open Source Technology Centre
> 
> 
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky