[poky] [PATCH 0/4][Image Creator]Put extra requested fields into different cache files

[Ke, Liping]

Hi, Richard

> > >
> > > a) Adds "bitbake_mode" and allows UIs to define cache data
> > > b) Adds the cache data to hob
> > > c) Drops the cache data used only by hob from the core
> > Yes, in general I want to do the same thing. Each patch in the serial will
> > not break the current cs. Patch[1/4], patch[2/4]& patch [3/4] are for a) and
> b).
> > But for c), because of the implantation algorithm I adopted, it's merged with
> > extra cache data implementation (the biggest patch).
> 
> That's fine, your original series didn't seem to work quite like this
> though and looked like I'd get failures if I only applied the early
> patches from what I remember.

sure, I understand this. I will make sure that the series of patches works independently
when resending the patch.

> 
> > > I've also the following comments on the code in general:
> > >
> > > a) Could we move the hob specific cache data from cache.py to hob.py. If
> > > not, I'd like to understand why not and maybe address those issues. My
> > > point is you shouldn't need to change cache.py to add extra cache data.
> >
> > you mean that we will have a separate ExtraCache (I guess hob or
> adt-installer should have the similar logic?)
> > implementation file, which has similar functionality with cache.py?
> > Oh, I did not think of this implementation at all when implement. In my mind,
> change less code is the principle since
> > this part of the code is the core of bitbake:)  If split, many codes in cache
> could be reused by both cache.py and hob.py?
> 
> I'm thinking that cache.py defines the class but the hob specific
> definition using that class to extend the cache data should be part of
> the hob codebase. In the future there may be external UIs calling into
> this code and needing this functionality and I'd prefer them not to each
> need to change cache.py.

Hi, Richard, just a question here. You mean ext-hob-cache data will be a sub-class
of cachy data? Inheritance here? We originally consider this, yet just failed to find
a good way. Namedtuple has the static dict fields. So namedtuple class can't be extended.
For inheritance, I must change the original cache.py implantation. 
Just want to hear your suggestion here...

> 
> > And also, if you think it is a must, could we split the task, for this phase, keep
> it in the same file.
> > And then refactory them in another patch later? Seems there're many tasks
> for image creator? Seems the schedule is
> > tight?
> 
> If you don't think this is realistic in the time available, I might be
> able to take a look at it.

Oh, I guess Jessica will re-arrange the schedule today... Seems for the task, there're
many different understanding about the requirement at the very beginning... I will try to
understand all the details before writing the code -:)
 

> No, I mean can we could pass:
> 
> bitbake_mode = ['hob', 'autobuilder']
> 
> and it then uses three cache files so bitbake_mode would become a list
> rather than a single item.
> 
OK, I understand this requirement now.
After we sync up today, I should have a clearer understanding about the requirement and I will redo the patch!

Thanks a lot for your help!
criping


> Cheers,
> 
> Richard