To enable developers on Windows systems, it would be helpful if they could launch and use our tooling on that platform. Currently the ADT as it stands today could probably be made to work there but it would require significant effort. We need to consider where the ADT developer experience needs to be in the future as well. Our current problem is that a user can use the ADT to build a single app easily but there is then a brick wall/cliff problem of them needing the full bitbake environment to build an image. In the future a spectrum of different points between these two is envisaged, e.g. a user devloping an app and adding it to a standard image. Various tools like locked sstate are clearly involved but the reality is we need bitbake too. We have two options: a) Try and get bitbake to run on windows b) Run things in a VM and provide easy accessibility to windows users The first option is on a road to insanity, we have neither the manpower of the will to do it, it would adversly affect bitbake's performance on Linux. The second option is the one we're therefore going to pursue. With this in mind, we need to create some tooling/application around: a) Starting up qemu and launching a build environment within it b) Providing a shell interface over ssh to that build environment c) Enabling samba in the image so that the build contents can be mounted on the host system With those basic components working, we could explore hob/toaster/eclipse integration around the basic core.
Option "b) Run things in a VM and provide easy accessibility to windows users" was chosen.
Using meta-mingw layer (http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw/) bitbake is able to produce a native Windows qemu. At the moment, qemu is not able to run, due to the lack of proper support for Windows dynamic libraries (finding the system/user libraries, basically).
Starting point: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ciorga/nativesdk-qemu-win32
It would be easier to use VirtualBox VM instead of qemu at the beginning. Once it is decided what works best (eclipse, toaster, Hob, ...) then we can switch to qemu to Windows.
As a first step, I managed to cross compile qemu for Windows: SDKMACHINE="i686-mingw32" bitbake nativesdk-qemu Then I was able to run qemu-system-i386.exe with a core-image-minimal.ext3 under Windows (text-only mode).
I created a set of recipes for a VirtualBox VM: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=juro%2Fpoky-vm You create the VM by: $ bitbake poky-vm This will create a Zip file containing VM, start-up scripts for Linux and Windows and a README.txt file. Assuming you have VirtualBox installed, simply unzipping the Zip file in any folder and double-clicking a startup script should boot the VM. It is possible to connect to VM via SSH and start a bitbake operation: $ cd poky $ . ./oe-init-build-env $ bitbake <...> The VM folders are accessible via Samba shares. It is also possible to share Windows folders via CIFS, if needed. The start-up scripts can be modified (#of CPUs, memory size etc.) I encountered some problems with "time in the future". (These will hopefully go away with Guest Additions)
Version controlled the works in: https://github.com/otcshare/meta-yocto-vm-experiments Put on hold for the time being, as there are better alternatives being developed/implemented at this time.
verified as per above comments.