Re: RFC: Improving the developer workflow

[Mike Looijmans <mike.looijmans@topic.nl>]

On 08/07/2014 11:10 AM, Paul Eggleton wrote:
...

> * Provide tools to allow modifying software for which a recipe already exists.
> If the user has an external source tree we use that, otherwise we can fetch
> the source, apply any patches and place the result in an external source tree,
> possibly managed with git. (It's fair to say this is perhaps less of an
> application developer type task, but still an important one and fairly simple
> to add once we have the rest of the tooling.)

This has been the most awkard of all OE uses so far. It hasn't improved 
over the years either.

In general, people (both external customers and internal colleages) have 
no objection whatsoever to cloning the OE repos and running bitbake 
themselves.

I haven't been able to come up with a good solution. I always try to 
test and develop my software on a regular PC, but for some things (e.g. 
access to the FPGA, or optimizing inner loop code with NEON 
instructions) you can't do without actual on-target deployment.

So I usually end up with a mix of manual commands and special-purpose 
shell scripts that work for just one package. For small packages, I tend 
to commit locally, and then re-run the package up to the "install" 
phase. For big things that take several minutes to compile I'm usually 
manually moving files around and struggling to keep the files in my 
repository and what the build will see in sync.

Any small step forward in this area will be a giant leap for the 
developers...

>
> * Provide tools to get your changes onto the target in order to test them.
> With access to the build system, rebuilding the image with changes to a target
> component is fairly trivial; but we can go further - assuming a network
> connection to the target is available we can provide tools to simply deploy
> the files installed by the changed recipe onto the running device (using an
> "sstate-like" mechanism - remove the old list of files and then install the new
> ones).

If it's possible to run the "install" target, this may be as simple as 
making a tar from the installed "image" directory and unpack it on the 
target.
I tend to do this in a one-liner if I have ssh access:

tar -cf - -C tmp.../${P}/image . | ssh target tar xf - -C /

I think that covers 99% of the use cases I can come up with...

> * Provide tools to get your changes to the code or the metadata into a form
> that you can submit somewhere.

If you have git in the "modify recipe" stage, this should be a breeze. 
Just use git push/bundle/send-email/format-patch/... to send them where 
they need to go.

Mike.