summaryrefslogtreecommitdiff
path: root/meta-demoapps/recipes-gnome
diff options
context:
space:
mode:
authorChris Larson <chris_larson@mentor.com>2010-11-16 12:58:52 -0700
committerRichard Purdie <rpurdie@linux.intel.com>2011-01-04 14:46:42 +0000
commitacca3440579b5d5149bc951b6c6edafc018f45be (patch)
tree9d2951324b621297414c32bb1e882e3904db484f /meta-demoapps/recipes-gnome
parentc6328564de8e8cae113ee559d769105f9f4b6003 (diff)
downloadopenembedded-core-acca3440579b5d5149bc951b6c6edafc018f45be.tar.gz
openembedded-core-acca3440579b5d5149bc951b6c6edafc018f45be.tar.bz2
openembedded-core-acca3440579b5d5149bc951b6c6edafc018f45be.tar.xz
openembedded-core-acca3440579b5d5149bc951b6c6edafc018f45be.zip
cache: create and use a RecipeInfo class
This class holds the particular pieces of information about a recipe which are needed for runqueue to do its job. By using it, I think we improve code clarity, reduce method sizes, reduce overuse of primitive types, and prepare for parallel parsing. In addition, this ditches the leaky abstraction whereby bb.cache attempted to hide the difference between cached data and a full recipe parse. This was a remnant from the way things used to be done, and the code using it had to know the difference anyway. If we choose to reimplement caching of the full recipes, we can do it in bb.parse, in a completely transparent way. (Bitbake rev: 992cc252452221f5f23575e50eb67528b2838fdb) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Diffstat (limited to 'meta-demoapps/recipes-gnome')
0 files changed, 0 insertions, 0 deletions