[oe] Interactive task handling in Bitbake

[Richard Purdie]

As some will have noticed, "interactive" tasks such as devshell and
patch aren't working properly in bitbake trunk when the -b option isn't
used. The problem comes about when the multithreading code is active as
the forked processes no longer have proper access to stdin/stdout.

I've given quite a lot of thought on how to solve this both to fix the
current problems and to fix the even worse problems we'll have when we
split bitbake into a client and server where the server might not even
be on the same machine as the client.

This morning, a solution hit me and I now have a proposal on how we
could handle this. My plan is to take advantage of X's remote display
functionality so when bitbake drops to a shell it does so over the
standard DISPLAY environment variable. This has the benefit of being a
well established standard than can be setup in a number of widely
documented configurations (such as over ssh tunnels) and presents no
arbitrary limits such the number of interactive tasks we can run at
once.

It should be on record, I never want bitbake to *have* to use
interactive tasks. Bitbake should be capable of unattended operation
either when an X display isn't present or its an automated build eg. an
autobuilder or QA tests/builds. This currently is the case as the
devshell task is an optional task and the patch class has the NOOP
resolver.

I've yet to work out the specifics of this plan and it will probably
happen in stages. Initially, I guess it will rely on some standard
terminal applications being present on the server, eventually bitbake
might build its own native version of one of these. This would be a lot
easier if we can remove the special case of native .bb files, something
I'm also giving thought to in the longer term.

For now, I think it would be enough for bitbake to be able to launch a
variety of terminal programs and if people want interactive support,
they need to ensure one is installed on the server. I've not even tested
the specifics of doing this, but it should at least be technically
possible :).

Does anyone see a better way of handling this (or object to this plan)?

Cheers,

Richard