Re: My thoughts on the future of OE?

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

On Thu, May 01, 2014 at 06:02:41PM +0100, Richard Purdie wrote:
> I was asked what I thought were things that needed discussion at OEDAM.
> Sadly I won't be there but I thought it might help to write down my
> thoughts in a few areas.
> 
> Developer Workflow
> ------------------
> 
> Firstly, I think the big piece we need to address as a project is
> "developer workflow" as this is where people are struggling using it.
> 
> Unfortunately "developer workflow" means different things to different
> people? Which one do I mean then? I actually mean all of them. As some
> examples:
> 
> -----------------------------------------------------------------------
> 
> * A kernel developer wanting to rebuild a kernel 
>   [on/off target, with the ADT/SDK or a recipe]
> * A kernel developer wanting to build a kernel module
>   [on/off target, with the ADT/SDK or a recipe]
> * An application developer wanting to build a single App
>   [on/off target, with the ADT/SDK or a recipe]
> * An application developer wanting to (re)build a library, linking an 
>   App to it
>   [on/off target, with the ADT/SDK or a recipe]
> * A user wanting to rebuild an image with a package added
>   [on and off target - feeds or a build]
> * A user wanting to rebuild an image with more advanced changes

One more workflow I see quite often and really isn't supported well is:

* An application developer wanting to (re)build just one library and one
  test application, verify on target, iterate as long sa needed and then
  do "clean" build which will rebuild everything depending on it (not
  just the test app)

Real world example is newer eglibc breaking audio from qtmultimedia, so
the test app is depending on all qt* crap which takes forever to build
and every developer change to eglibc will basically trigger rebuild of
everything.

We need an easy way to do such "simplified" builds where you don't care
much about reproducibility. Currently most developers I know will do
devshell/source run.do_foo  for eglibc and the test-app + rsync/scp of these 2 changed
binaries to your target device to verify if the fix works.

The bitbake -S improvements help to find "why" the build rebuilt so many
components, but doesn't help with preventing it (see 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]