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 _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
