[OE-core] [RFC PATCH 0/7] Developer workflow improvements

[Paul Eggleton]

On Friday 28 November 2014 12:28:00 Trevor Woerner wrote:
> These tools are really nice! Some thoughts/comments:
> 
> Maybe the "devtool.conf" that gets created could be placed in the
> "conf/" subdirectory (along with the other configuration files such as
> local.conf and bblayers.conf)?

Yes, that's a good idea, I'll change that.
 
> Perhaps any recipe you're working on could be automatically included via
> an IMAGE_INSTALL_append in conf/local.conf (or maybe that's too intrusive?)?

This is something I'd wanted to do - it's certainly something that should be 
made easy, but I was concerned about causing a full reparse just because of 
adding that to local.conf. (There might be a workaround through some sort of 
packagegroup for containing the packages produced by the recipes in the 
workspace that is added once when we create the workspace - maybe that's the 
answer?)
 
> Do you envision users creating multiple workspaces? I'm wondering why
> "devtool create-workspace" is required. Is there any advantage to
> requiring users to create the workspace explicitly instead of just
> having it be created implicitly?

I wouldn't expect users to want to create multiple workspaces, but I did want 
users to be able to (a) choose where their workspace would go and (b) know 
that it has been created, so that the workspace layer showing up in the 
configuration isn't a surprise.
 
> Some of the commands to "devtool" include things like
>     - extract
>     - build
>     - deploy
>     - undeploy
> but when a workspace is created, devtool (very intelligently) adds the
> workspace to the set of BBLAYERS. So one could then just use bitbake to
> build the recipe. Are there any advantages to using "devtool build
> <recipe>" instead of "bitbake <recipe>"?

Not at the moment, although it is a convenient shortcut for "bitbake -c 
install <recipename>" (which is all you need to do for "devtool deploy" - note 
that "deploy" is distinct from our do_deploy, it could perhaps benefit from a 
better name). The other reason it's there is more for use as part of the SDK 
where the intention is to do everything through the devtool command, although 
that is a usage model that isn't enabled yet.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre