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
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
