All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: Yocto usability questions
Date: Wed, 16 Nov 2011 17:39:46 -0600	[thread overview]
Message-ID: <4EC449C2.1000706@windriver.com> (raw)
In-Reply-To: <CA+YB3ray8bX94Y1subz+7CQYUzRJWjHS2CQX_W2boA2BV7A5ZA@mail.gmail.com>

On 11/16/11 4:07 PM, Jeff Osier-Mixon wrote:
> Mark Hatle said:
>
>     Yocto is a cross-compiled build environment. This is a departure to a lot of
>     the Moblin/MeeGo work that has occurred in the past. The advantages are you
>     can use any commodity PC to target any (supported) architecture.
>     Disadvantages are that when you introduce new code, you need to ensure that
>     it has a recipe (build instructions for bitbake) and can cross compile. If
>     everyone has to do the same work over and over, this can be time consuming
>     and counter productive. If people work together, the time and support burden
>     are dramatically reduced. This can help negate issues people have had in the
>     past with cross compiling. Note: Yocto -does- have a self hosted compile
>     environment if it is needed, this is usually when cross compiling isn't easy
>     to do for some reason.
>
>
> Mark & everyone else listening:
>
> Would you say that (1) the need for a recipe and (2) the requirement to
> cross-compile are two of the most major usability or learning-curve
> disadvantages of working with the Yocto Project (and oe-core)? What would be a
> third disadvantage from a usability standpoint?

1) Recipe isn't needed, unless you want automatically reproduced builds and to 
share the instructions with others... which is one our our goals.

I don't see the recipe as anything different then an SRPM, Debian src.tgz, etc. 
  The only obstacle is that it's "different" that what desktop distributions do.

2) I think cross compilation is by far the largest obstacle.  People not 
familiar with the GNU auto tools, cross compiling in general, or simply 
inexperienced developers seem to have a lot of problems with this.  I think 
OE/Yocto does a good job at providing GNU auto tools and make helpers, but it's 
far from perfect.  As far as how to improve it...  we need to keep incrementally 
improving our support, documentations and examples.  We also need to foster a 
community where people share the work they've already done... thus eliminating 
this issue.  (The meta-oe layer is a good place for this already.)

I'm sure there are other usability issues, but I've been doing cross compilation 
for so long that I'm a bit blind to some of the issues.

To me the biggest thing we need to do is make sure someone who is familiar with 
desktop Linux can step in and apply what they know to building a recipe and 
fixing cross compilation problems.  If we can do that -- it will go a long way 
toward helping resolve the issues that cause people to do self-hosted 
compilation on slow target systems.  (Note there are some things that are simply 
complicated and difficult to do like Firefox.. for those the only answer is to 
have "experts" do the work and make it available to the novices so they can see 
and understand how to work around various issues.)

> Another way to put it: if you could change three things about the Yocto Project
> to make it more approachable for someone who has never used it before, what
> would they be?

To re-iterate:

*) We need a resource for contributed packages (meta-oe?) that will eliminate 
most of the problem.

*) We need good examples of problems and solutions to cross compilation difficulties

*) We need to continue to identify "common" issues and work to resolve them in 
the tooling we already support

--Mark

> --
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
> <http://yoctoproject.org/>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



  reply	other threads:[~2011-11-16 23:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 22:07 Yocto usability questions Jeff Osier-Mixon
2011-11-16 23:39 ` Mark Hatle [this message]
2011-11-17  4:03   ` Ourada, Paul
2011-11-17  7:19 ` Koen Kooi
2011-11-17 13:06 ` Rainer Koenig
2011-11-17 14:25   ` Philip Balister
2011-11-17 21:38 ` Chris Tapp
2011-11-17 22:17   ` Brian Duffy
2011-11-17 23:19     ` Osier-mixon, Jeffrey
2011-11-18  9:40   ` Jack Mitchell
2011-11-18 15:02     ` Ourada, Paul
2011-11-18 15:42       ` Philip Balister
2011-11-18 15:56       ` Gary Thomas
2011-11-18 16:00         ` Philip Balister
2011-11-18 16:04           ` Gary Thomas
2011-11-18 16:56             ` Tom Rini
2011-11-18 16:56             ` Jack Mitchell
2011-11-18 17:20       ` Osier-mixon, Jeffrey
2011-11-18 19:40         ` Jeff Osier-Mixon
2011-11-18 20:12     ` Joshua Lock
2011-11-18 20:54       ` Tom Zanussi
2011-11-18 21:31         ` Osier-mixon, Jeffrey
2011-11-18 21:56           ` Chris Tapp
2011-11-18 22:32           ` Philip Balister
2011-11-18 22:36             ` Osier-mixon, Jeffrey
2011-11-22 12:52         ` Rainer Koenig
2011-11-22 15:23           ` Tom Zanussi
2011-11-22 16:49           ` Joshua Lock
2011-11-22 21:03             ` Chris Tapp
2011-11-22 22:52               ` Joshua Lock
  -- strict thread matches above, loose matches on Subject: below --
2018-12-21  5:16 Prasenjit Mahanti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC449C2.1000706@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.