[oe] Using widgets to add structure to OpenEmbedded

[David Farning]

Using Widgets to add structure to BitBake/OpenEmbedded.

The purpose of BitBake and OpenEmbedded is to create an image of a
distribution which will run on a target machine.

One of the most challenging aspects of describing OpenEmbedded is
defining where a specific type of information is
defined.  By not clearly specifying where information is defined, the
SPOT (single point of truth) principle is violated.

There is always a trade-off between flexibility and introducing
structure into a system.  In the case of BiteBake and
OpenEmbedded, which solve a very specific problem, more is gained than
lost by introducing structure.  

Graphical toolkits do a very good job of exchanging flexibility for
structure by using widgets.  Everything is gtk+ is
a widget.  Widgets have generic properties and methods which can
easily be overridden.  Widgets can contain other widgets.

Similarly, BitBake and OpenEmbedded can be broken down into a number
of widgets.  Each widget type represents a layer which
define domain specific parameters and methods. Below is a possible
widget hierarchy     

1. Host Machine.
  a. Set up build structure.
  b. Native compiler.

2. Target Machine.
  a. Target architecture.
  b. Cross compiler.
  c. Target specific device drivers.

3. Image
  a. Target file system type.
  b. Target root file system.

4. Distro
  a. Features to include in distribution.

5. Tasks
  a. Container which includes predefined sets of packages.

6. Packages
  a. Individual software packages.

For flexibility, a widget can contain any widget of a lower type. 

Interesting, because the conf parser is the same as the .bb parser,
setting up such a widget based hierarchy would not involve
any significant changes to bb or oe.

Bbclasses would define generic widgets.

Widgets are created by inheriting from the correct bbclass.
Widget override generic functionality by setting variables and
defining methods
Widgets can contain child widgets by including other bbfiles.

Does anyone see any obvious problem with such a system before I start
testing it?

This type of structure would make the documentation much easier.  It
would also significantly reduce the OpenEmbedded learning curve. 

Thanks
David Farning