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

Paul Eggleton paul.eggleton at linux.intel.com
Tue Dec 2 11:46:21 UTC 2014


On Monday 01 December 2014 23:36:23 Trevor Woerner wrote:
> On 12/01/14 05:11, Paul Eggleton wrote:
> > On Friday 28 November 2014 12:28:00 Trevor Woerner wrote:
> >> 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?)
> 
> Maybe even just printing a bit of text after a successful "add" to
> inform the user that the just-added project isn't part of any image and
> what they might want to do to include it?
> 
> The packagegroup sounds good too. But if the user doesn't want it
> included, they might be confused about how it magically appeared, and
> have some trouble finding how to remove it.

Right. I might defer this until we get to the SDK part where we'll need 
something to handle this (since the aim in that case is to avoid any editing 
of conf files or interacting with bitbake directly).

> >> 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.
> 
> I can't help think that there's no harm in an unused workspace (is
> there?). Maybe the empty workspace from "create-workspace" should just
> be created by default by the "oe-init-build-env" tool (or whatever a
> given project is using).

I guess my thought was that some people are fussy about their setup, and this 
is a bit of a new thing.

> If I were writing the documentation for this workflow, or giving a
> presentation on it... I'm just trying to figure out how to justify the
> extra, empty (but necessary) step of creating the environment before
> using it. Maybe if someone tries to add a project before creating the
> workspace, instead of erroring out, just run the create-workspace for
> them with the defaults. If they're a power user who wants to put the
> workspace somewhere specific then they're free to explicitly call
> create-workspace on their own, otherwise it'll get called with the
> defaults for them (or created automatically as part of the
> oe-init-build-env).
>
> To borrow the analogy from git: create-workspace is part of the pluming;
> it's there if people what to call it explicitly, otherwise it gets
> called implicitly with defaults?

Actually you make a very good case; auto-creating it (and stating so) might be 
better than failing. I'll make the change.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list