LesserKnownFeatures

Let’s go over a few Yocto/OE capabilities which seem to be less commonly known.

Variable Typing

---

The first item I will cover is the "Variable Typing" support. This feature allows one to declare the 'type' of a given metadata variable. This both enables a type check to ensure that it's syntactically valid, and returns an object of the appropriate type when using the python interface. Admittedly, this is promotion of something I created, but I do believe there's value here, and future posts will cover a variety of features created by a variety of individuals.

The implementation in oe-core consists of two components:

• Type creation python modules, 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
• Consolidates the logic surrounding what to do with the value of a given variable. For variables like PATH, this is simply a split(), but for boolean variables, any duplication can result in unclear semantics. For example, we may not know whether our choices are 1/0, empty/nonempty, true/false, etc.
• 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')

To enable configuration time type checking of the config variables which have the appropriate metadata, set the following: `INHERIT += "typecheck"`. This is done by the 'mel' distro automatically.

List of currently available types: list, choice, regex, boolean, integer, float

An example of the appropriate metadata with failing typecheck:

   BAZ = "foo"
   BAZ[type] = "boolean"
   
   $ bitbake -p
   FATAL: BAZ: Invalid boolean value 'foo'

Further examples of metadata values:

   FOO = "alpha"
   FOO[type] = "choice"
   FOO[choices] = "alpha beta theta"
   
   PACKAGES[type] = "list"
   
   LIBTOOL_HAS_SYSROOT = "yes"
   LIBTOOL_HAS_SYSROOT[type] = "boolean"
   
   PATH[type] = "list"
   PATH[separator] = ":"

Examples of usage of these from python:

   python () {
       import oe.data
       for pkg in oe.data.typed_value("PACKAGES", d):
           bb.note("package: %s" % pkg)
       
       for path in oe.data.typed_value("PATH", d):
           bb.note("PATH element: %s" % path)
       
       assert(oe.data.typed_value("FOO", d) == "alpha")
       assert(oe.data.typed_value("LIBTOOL_HAS_SYSROOT", d) == True)
   }

OE python package

---

The OE python package has a number of modules which provide some valuable pieces of functionality. Please, take the time to look over these modules before writing any python in the metadata, as they can prevent unnecessary reinvention of the wheel.

Examples (random selection of bits from the oe package):

• oe.path.relative - return a relative path from src to dest
• oe.path.copytree - recursively copy a tree from src to dest
• oe.path.find - acts like the ‘find’ command, traversing a tree and yielding the full paths to the files
• oe.utils.inherits - return True if the metadata inherits from any of the specified classes

Classes

---

• externalsrc

This class is used to build from an existing local source tree, rather than the usual fetch/unpack/patch process. This is an invaluable tool for active development.

• gitver/gitpkgv

gitpkgv is used to extract the version from a git repository referenced from SRC_URI, and use it in the package versioning. gitver is used for the same purpose, but to extract from a local repository, rather than a bitbake fetched repository

• lib_package

This class is used to split out the binaries from the main library for recipes whose primary artifact is the library

• recipe_sanity (used via INHERIT)

This class is used to run a set of basic sanity checks against the metadata of a recipe. It checks for some common user errors.

• archiver (used via INHERIT)

This class is used to archive sources/patches/logs for a recipe, usually for license compliance. It is quite configurable, to cover the common use cases, and ensure it can meet the needs of any legal department.