From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2007-06-07 08:24:34
go ahead and call me crazy :) I couldn't sleep last night thinking
about the problems that boost has with the testing process.
Although the roots of my idea were different it turns out to be very
similar to well known SETI_at_Home project. Therefore I call it Boost_at_Home :)
Solution is simple in following steps:
1. create a vmware image with operating system and a single compiler
installed. One vmware image per compiler to ease bugfix and upgrades
in the vmware images.
2. let people download as many images (compilers) as they want. They
will use it with freely available vmware-server to launch it.
3. After the virtual machine starts (with the compiler) a small
program will be automatically executed to await instructions from
4. The boost.org website will list the number of available virtual
machines and which tests they are currently running. No interaction
from the person who runs the virtual machine is required. Once it is
launched it obeys instructions from the central boost.org server.
1. vmware is free to use, but supports only x86 architectures.
Fortunately (to my knowledge) every compiler supported by boost has
some version working in x86 environment.
2. some compilers require propertiary windows OS. Giving away a clean
install of windows is prohibited. We can use ReactOS intead:
and install the compilers there.
3. It's possible that not every compiler has a version available for
free. I'm not sure - is that true? If yes then it's in their
interest to help us:
- we ask the to provide a free copy of their compiler for the
sole purpose of being used by Boost_at_Home project.
- alternatively we drop support for their compiler.
I have several machines lying around that could be used to help
boost. If deploying a testing farm will become as easy, as downloading
a vmware image and starting it - it's obvious that many people will
The capcity of boost testing farm can increase more than tenfold!
-- Janek Kozicki |
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk