[oe] Interactive Task handling

Richard Purdie rpurdie at rpsys.net
Wed Mar 28 20:06:48 UTC 2007


A while back I made a proposal for interactive task handling in future
incarnations of bitbake. The problem was basically that with
multithreading, having one task owning and having access to the terminal
becomes problematic. My proposal was to lever the power of X and/or
utils like screen.

There are currently two areas where interactive tasks are used in OE:

1. The "user" patch resolver
2. The devshell task

As mentioned previously, interactive tasks are always going to be
"extras" to bitbake to aid development and unattended builds of OE will
continue to be possible.

I've made a patch which shows roughly what I'm proposing and converts
the above two users:

http://www.rpsys.net/openzaurus/temp/oe-terminal-r3.patch
(the patch is against poky but the same principles apply for OE.dev)

The user sets TERMCMD and TERMCMDRUN to their custom command or one of
the provided standard ones in their local.conf. There are examples there
which work with screen, gnome-terminal, kconsole and xterm.

devshell simply fires up whatever is in the TERMCMD variable.  The patch
resolver is more complex since we need to show the output of the failed
patch so TERMCMDRUN is similar but allows you to specify an rcfile
containing commands to run in the terminal first.

The big advantage of this is that it scales to the case where client
(UI) and server are separate machines, all that is needed is a valid
setting for the DISPLAY variable. No invention of protocols is needed
for the tricky piping I/O over some transport and any X application will
work (kdiff3 for patch resolution springs to mind).

The disadvantage is that it will cause "random" windows to appear which
may cause issues with UI integration. I suspect longer term, we can
write a simple external program to handle this and connect to the UI at
least for the terminals case so I'm not unduly concerned.

I'm also aware the screen command triggers a new screen session rather
than joining an existing one. I couldn't find a way to make the screen
command block on command completion without doing that. Any pointers
from screen gurus welcome :)

The above patch makes interactive tasks with bitbake 1.8.x and trunk
usable again so I plan to check something like this patch in unless
anyone objects or can see a better way to handle things.

Cheers,

Richard







More information about the Openembedded-devel mailing list