[bitbake-devel] [PATCH 1/1] data_smart.py: make use of expand cache in getVar()

Richard Purdie richard.purdie at linuxfoundation.org
Tue Aug 30 21:09:38 UTC 2011


On Mon, 2011-08-29 at 22:21 +0800, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Xu, Dongxiao
> > Sent: Monday, August 29, 2011 9:16 PM
> > To: Richard Purdie
> > Cc: bitbake-devel at lists.openembedded.org
> > Subject: RE: [bitbake-devel] [PATCH 1/1] data_smart.py: make use of expand
> > cache in getVar()
> > 
> > > -----Original Message-----
> > > From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> > > Sent: Monday, August 29, 2011 9:13 PM
> > > To: Xu, Dongxiao
> > > Cc: bitbake-devel at lists.openembedded.org
> > > Subject: RE: [bitbake-devel] [PATCH 1/1] data_smart.py: make use of
> > > expand cache in getVar()
> > >
> > >
> > > I'm left wondering why we don't key that cache on the unexpanded value
> > > rather than a specific variable name (or name+flag).
> > >
> > > I'll take this patch but its something we should consider...
> > 
> > Thanks, I will step into this point further and see if (name+flag) type of cache
> > could benefit us more.
> 
> Sorry I must misunderstand your point just now...
> 
> For caching of unexpanded value, there are too many/uncertainty of types, like:
> 
> ${TUNE_ARCH}
> ${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0] or 'defaultpkgname'}
> ${@bb.utils.contains("TUNE_FEATURES", "m32", "${X86ARCH32}", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "mx32", "${X86ARCH64}", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}
> 
> For simple variables, it is easy to cache, however for the expressions, it may not suitable to cache.

It shouldn't really matter what the expression is, we should just be
able to cache the value it evaluates to. We invalidate the cache upon
any write to the data store that can potentially change a variables
contents.

This shouldn't really be any different to the current behaviour of the
code (where caching doesn't cause a problem).

Cheers,

Richard





More information about the bitbake-devel mailing list