[OE-core] [poky] Proposed Multilib Implementation Brainstorming

[Esben Haabendal]

Richard Purdie <richard.purdie at linuxfoundation.org> writes:

> On Wed, 2011-04-06 at 15:21 +0200, Esben Haabendal wrote:
>> Richard Purdie <richard.purdie at linuxfoundation.org> writes:
>> 
>> > On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote:
>> > I actually believe the core in OE is well suited to multilib support and
>> > using it will show off some of the power in the OE architecture as I
>> > think we can do it better than anyone else before!
>> 
>> The one thing that in my experience pushes most people in other
>> directiosn than OE is the complexity.  Unless OE made simpler, I think
>> it will be quite hard to reach the goal of significantly reducing the
>> number of build systems.
>>
>> I am uncertain to what effect multilib in OE will have (positive and
>> negative), but it is clearly not making OE simpler.
>>
>> I just kind of makes things a bit ehmm... hopeless that the requests I
>> (and others with similar customers) hear from companies are considered
>> out of line for OE evolution, whereas the requests you and others hear
>> can be used as valid arguments for which directions to take.
>> 
>> It is not that I think it will add considerable burden, but is just yet
>> another brick to the wall to pass for developers trying to understand
>> OE.
>
> Nobody is saying requests for simplicity or ease of use are out of line,
> far from it. Its something that is being worked on by Yocto quite
> heavily. What does differ is the approach though, yours is to rip out
> anything you personally don't need,

That's not fair.  While I do "rip out" (to use your choice of colorful
term) stuff in OE-lite, I do and did not proppose to rip out any
features from OE.  I did comment that sstate as a pice of code might not
be give as much value if some of the concepts from OE-lite were
implemented.

> Yocto is taking a more reasoned approach to this and asking questions
> like:

Sorry, but I must take offence on that remark.  I do not feel that your
approach is anymore reasoned than mine.  It is different, and you
clearly prefer your approach, I don't question that.

> "What can we do to make things easier for new users?"
> "Can we make error messages more user friendly?"
> "What code do we have that is needlessly complex and can be simplified?"
> "If we are going to add a new feature, how was we reuse existing
> established concepts?"
> "If something is complex and hard to understand but required, how can we
> document or better explain the concepts to people?"
>
> I'd go as far as to say that things are getting more understandable and
> easier too. Yocto ran an alpha test programme where we took a selection
> of people, some with experience and some with no experience of
> embeddded, pointed them at the quick start guide and asked them to build
> an image, boot it and experiment. The results of this programme with
> Yocto 1.0 are orders of magnitude better than 0.9. This at least shows
> the new user experience is better than it was. Its not the only area
> that needs improvement and there is a long way to go but its a very
> positive start IMO.

Yes, that is measuring Yocto "user" usability.

I am at least as much concerned with long-time developer usability.
Given the amount of long-time developers normally available in OE, I
find it disappointing that at any time, almost noone (at most a very
small handful) dares to comment on RFC's touch core parts, such as
BitBake and gcc/glibc recipes.  I am firmly convinced that "we" (whoever
that might be) can do better than that.  I also believe that this is one
of the biggest reasons that there are so many embedded Linux
buildsystems.  Most people agrees that OE is among (if not the) most
advanced embedded Linux build system, but many of them end up using some
of the simpler tools.  With careful design, and constant refactoring, I
believe that you can lead in both features and simplicity, but you have
to accept that code and design concepts will be discarded when something
better turns up.

/Esben