Thanks to Måns for modifying the FATE script in a way that supports automatically cross compiling FFmpeg for a different target CPU on a faster host machine, transferring the binary to a machine specimen that runs the target CPU in question, and remotely asking the target CPU to run the battery of FATE test specs. The upshot of all of this is that FATE is effectively running on an ARM-equipped Beagle Board and contributing results back that anyone can view via the main FATE page.
I hope to get his changes rolled into the main script soon. It’s great work, and I’m hard-pressed to name another continuous integration system that can operate on such diverse platforms, environments, and circumstances.
I dusted off my old Sega Dreamcast this evening — the one I used to do homebrew programming on — and enjoyed some games. As I was playing, I realized that the next evolution of FATE would be to get it to continuously run automatic cross-compile and test cycles on the Dreamcast’s SH-4 via a custom serial protocol, similar to what John Koleszar described in this comment.
But I have a few more FFmpeg code paths to cover before I can even think about that.
Great work.
But current Fate report “The build (or perhaps the build machine) is very broken; please fix”…
BTW it could be interesting to get some execution time graph to catch speed regression on different hardware.
Funny thing that the ra144 test fails. I have no idea of what can be causing it…
@mat: Looks like Mans fixed it. Digging into the details, it looks like the host system was able to cross-compile the build but not transfer it to the target machine and SSH in to run tests.
Oh, and we will have graphs eventually. I have tons (gigabytes, really) of data in the FATE database and I just need a good way to present it in graph form.
The target board crashed, which of course prevented tests from running.