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

Paul Eggleton paul.eggleton at linux.intel.com
Tue Dec 9 16:08:45 UTC 2014


On Tuesday 09 December 2014 10:39:05 Trevor Woerner wrote:
> On 12/09/14 10:10, Paul Eggleton wrote:
> > On Tuesday 09 December 2014 10:00:51 Trevor Woerner wrote:
> >> Would it be possible to make the output of devtool be nice and colourful
> >> like the output of bitbake?
> >> 
> >>> Good idea, this is now done on the branch as well. "devtool build"
> >>> doesn't support colour in the bitbake output, but that's because colour
> >>> support in bitbake is switched by whether the output is going to a TTY
> >>> and stdout is being redirected in this case. (I guess we could add a
> >>> command line option for that as I have with devtool/recipetool.)
> >> 
> >> If it's not too much trouble I would like to ask that colour/curses be
> >> possible/enabled by default. Trying to find the error in all that output
> >> is a "needle in a haystack"-like operation :-)
> > 
> > I don't think this is straightforward unfortunately. I'll have to look
> > into it.
> 
> Okay. Maybe it'd be best to just revert to bitbake? IOW, does the
> devtool tool need its own "build,deploy,..."?

We did talk about this in a previous email, but just to clarify:

"devtool build" isn't strictly required in this phase, I added it primarily to 
support future usage in the SDK where the intention is to do everything 
through the devtool command, although that is a usage model that isn't enabled 
yet. However, it is a convenient shortcut for "bitbake -c install 
<recipename>" (which is all you need to do for "devtool deploy" to be able to 
work.)

"devtool deploy" is not related to do_deploy - it places files for the recipe 
on a nominated target machine without having to worry about packaging; we have 
no other equivalent for this at the moment. Perhaps it could have a different 
name in case the naming overlap is confusing.

> >> I wonder if all the
> >> 
> >>     NOTE: Running setscene task 31 of 33
> >> 
> >> (/home/trevor/devel/yocto/build/poky/meta-poky/meta/recipes-devtools/gcc/
> >> gc
> >> c-runtime_4.9.bb, do_populate_sysroot_setscene)
> >> 
> >>     NOTE: recipe gcc-runtime-4.9.1-r0: task
> >>     do_populate_sysroot_setscene: Started
> >>     NOTE: recipe gcc-runtime-4.9.1-r0: task
> >>     do_populate_sysroot_setscene: Succeeded
> >>     NOTE: Running setscene task 33 of 33
> >> 
> >> (/home/trevor/devel/yocto/build/poky/meta-poky/meta/recipes-devtools/gcc/
> >> gc
> >> c-cross_4.9.bb, do_populate_sysroot_setscene)
> >> 
> >>     NOTE: recipe gcc-cross-i586-4.9.1-r0: task
> >>     do_populate_sysroot_setscene: Started
> >>     NOTE: recipe gcc-cross-i586-4.9.1-r0: task
> >>     do_populate_sysroot_setscene: Succeeded
> >> 
> >> Could be (should be) done as part of the "devtool
> >> create-workspace"/"devtool add" operation?
> > 
> > If running devtool along side someone's existing build environment,
> > wouldn't that be expected to be set up already? (All it does effectively
> > is "bitbake recipename")
> 
> Here are my steps:
> $ source meta-poky/oe-init-build-env build
> $ bitbake core-image-x11
> $ devtool add <myx11app>
> $ devtool build <myx11app>
> 
> at this point it does a bunch of these gcc-runtime tasks. So my first
> thought is: "why is my build going off into left field and doing all
> these other things when all I asked it to do is to build <myx11app>?".
> I'm guessing these gcc-runtime tasks are required for something related
> to devtool, and they only need to be run once. So maybe it would be best
> if they were run as part of creating the workspace (either explicitly
> with "devtool create-workspace" or implicitly with "devtool add")?

Trying to make "devtool add" or "devtool modify" do this just doesn't feel 
right to me. These operations are supposed to be quick, and if they end up 
running actual build tasks, they won't be.

My guess (with no other context) is that the reason you are seeing this is 
that you're building from sstate, and when it builds core-image-x11 it doesn't 
need some of the tasks that it then does need when it goes to build the 
individual recipe. I'm not sure, but I would expect that most people would be 
doing this from an existing build directory rather than starting with a new 
one. Is there a reason you're creating a new build directory as part of the 
steps above?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list