[oe] Using widgets to add structure to OpenEmbedded

[Leon Woestenberg]

Hello David,

On Nov 10, 2007 8:19 PM, David Farning <dfarning at gmail.com> wrote:
>
> 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.
>
Tthere are a lot of abstract objects in OpenEmbedded, some different
only by subtleties.

> 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.
>
The structure is there. It takes a steep learning curve to see what
the structure
is about.

> 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.
>
Objects.

Do not introduce widgets into BB/OE, you are throwing in a whole new
jargon that adds confusion, not structure!

> 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.
>
A cross-compiler belongs with a target machine? No, I don't buy that,
too confusing.

A cross-compiler compiles on a certain architecture, for a certain architecture.

> 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.
>
Sorry, I disagree. It would add MPOC (multiple points of confusion).

What is needed is a unambiguous description of what we have now, with the sole
purpose the smoothen the learning curve.

Regards,
-- 
Leon