aboutsummaryrefslogtreecommitdiffstats
path: root/lib/oe/types.py
AgeCommit message (Collapse)Author
2011-02-09More sane naming for the variable typing codeChris Larson
oe.types.value -> oe.data.typed_value This name has been bugging me. This function is the primary interface to the module for OE metadata, as it takes a variable name and datastore and returns an object of the correct type. While this function is part of the variable typing implementation, in reality it's more about giving you a useful object from the metadata, so I think oe.data is a more appropriate place for it. oe.types -> oe.maketype These are the functions which construct types, not the types themselves, so it was somewhat misleading. oe._types -> oe.types These are the actual types, any callable in this module becomes an OE type, using its arguments to determine the variable flags (optional and required) to obey. Will use __init__'s args in the case of an actual python class. Signed-off-by: Chris Larson <chris_larson@mentor.com>
2011-02-09oe.types: for invalid type, list valid onesChris Larson
Signed-off-by: Chris Larson <chris_larson@mentor.com>
2011-01-13oe.types: add/update docstringsChris Larson
Signed-off-by: Chris Larson <chris_larson@mentor.com>
2010-12-28Implement variable typingChris Larson
This implementation consists of two components: - oe.types python module, whose job it is to construct objects of the defined type for a given variable in the metadata - typecheck.bbclass, which iterates over all configuration variables with a type defined and uses oe.types to check the validity of the values This gives us a few benefits: - Automatic sanity checking of all configuration variables with a defined type - Avoid duplicating the "how do I make use of the value of this variable" logic between its users. For variables like PATH, this is simply a split(), for boolean variables, the duplication can result in confusing, or even mismatched semantics (is this 0/1, empty/nonempty, what?) - Make it easier to create a configuration UI, as the type information could be used to provide a better interface than a text edit box (e.g checkbox for 'boolean', dropdown for 'choice') This functionality is entirely opt-in right now. To enable the configuration variable type checking, simply INHERIT += "typecheck". Example of a failing type check: BAZ = "foo" BAZ[type] = "boolean" $ bitbake -p FATAL: BAZ: Invalid boolean value 'foo' $ Examples of leveraging oe.types in a python snippet: PACKAGES[type] = "list" python () { import oe.types for pkg in oe.types.value("PACKAGES", d): bb.note("package: %s" % pkg) } LIBTOOL_HAS_SYSROOT = "yes" LIBTOOL_HAS_SYSROOT[type] = "boolean" python () { import oe.types assert(oe.types.value("LIBTOOL_HAS_SYSROOT", d) == True) } Signed-off-by: Chris Larson <chris_larson@mentor.com>