This is a has turned into a larger problem than just retrofitting some python scripts to work on a windows mobile device. I have had success getting xpcshell and reftest results by fixing up the python scripts. Our biggest hurdle is getting subprocess.Popen functionality on a Windows Mobile device, especially capturing the output from the spawned process. How are we going to resolve this? I don’t know, but here are some ideas in the works:
- Write native code to create a process. This is the approach we have been taking so far using osce to launch a process and collect results in a log file. We can work around this, but there are issues calling these api’s multiple times.
- Rewrite subprocess to work with Windows Mobile. This is similar to the osce approach but instead returns handles to the python code to simulate stdout as well as kill the running process. This is a lot more code to write and would only be useful if we can fix the problems with osce. Some effort has been done here as seen in these notes.
- Use a remote api (rapi) harness from a host machine. This is similar to the communication process that Visual Studio uses to debug a process on a device. Ideally this would have the most support from Microsoft tools and API’s, but we decided to put this on the backburner as it will limit us to a 1:1 mapping of device/host.
- Write a native telnet/ssh server and shell. This is another approach that we have dabbled in but have not made much progress. Writing a telnet/ssh server on Windows Mobile is not too difficult, adding capabilities to do common tasks (ls, cd, mkdir, rmdir, cat, more, cp, scp) require even more code. As it stands this is good idea but has not had a lot of momentum.
- Write a telnet server that runs in xpcshell. This is something that blassey had mentioned yesterday. Currently we run a httpd.js web server from xpcshell, why not a telnet server that gives us a js prompt? Could be useful for our tests as we can launch a process and do file I/O. My concern here is how are we going to run the python code which creates profiles and reads files and directories to build up the list of arguments to then spawn fennec?
- Proxy python statements to run remotely on device. This was also an idea that blassey has come up with. Using the RAPI toolset we could have python test harnesses run on the host and instead of calling popen on “fennec “, it would call “ceexec.exe fennec “. This would work for getting results from reftest and xpcshell, but there will be problems with the python code when it is trying to create a profile or read a manifest file.
As you can tell, there are a lot of ideas out there, but no easy approach to resolve our problem. Part of the problem lies in Python as output from a python script is not easily collected. For example, if I launch a python script which prints out data from Visual Studio Debugger, I will see the PythonCE console on my device along with the output, but I will not see the output in my debugger window. This extends to the processes that are launched from inside of Python making it more difficult to collect results and debug.
Personally I like the telnet to xpcshell approach. It would require that we execute portions of the python test harness as individual scripts (e.g. creating the temporary profile). Alternatively using the RAPI tools could achieve the same thing if we had a good method for copying required files over to the device during runtime.
I am sure all of this is giving ctalbert and ted quite a headache just knowing I am talking about it. Minimizing the impact to the tests and harnesses is something I want to strive for, but if not, I can always send a fresh bottle of Tylenol to ease the pain.