Jeremy wrote:
the VMWare folks are not willing to provide a permanent license for VMWare to us.
So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate.
What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM...
On 02/03/2012 10:47 AM, Dan Kegel wrote:
Jeremy wrote:
the VMWare folks are not willing to provide a permanent license for VMWare to us.
So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate.
What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM...
No plan at all, which is an oversight.
I think we may have to have a 'real' Windows box to do any kind of credible D3D tests; perhaps we have to make the same argument for Mac OSX. But boy it sure would be nice if we could put MacOSX into a VM...
Cheers,
Jeremy
On Feb 3, 2012, at 10:13 AM, Jeremy White wrote:
On 02/03/2012 10:47 AM, Dan Kegel wrote:
Jeremy wrote:
the VMWare folks are not willing to provide a permanent license for VMWare to us.
So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate.
What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM...
No plan at all, which is an oversight.
I think we may have to have a 'real' Windows box to do any kind of credible D3D tests; perhaps we have to make the same argument for Mac OSX. But boy it sure would be nice if we could put MacOSX into a VM...
Yeah... Trouble is, you need to run it on a Mac anyway. (The host OS doesn't have to be Mac OS, but it has to be running on Mac hardware.) At least, that's my understanding of Apple's SLA for Mac OS X.
I have a launchd.plist (a config file for the Mac OS launcher daemon, their version of init, inetd, and cron all rolled into one) and a set of scripts that runs the tests every night after AJ commits. I've attached them here. The scripts expect to be run from the directory containing the Wine sources. The configuration is specific to my system (i.e. all the paths refer to directories in my home folder)--if anyone wants to use it, you'll have to change it for your system. Also note that the log file it produces needs to be turned over manually--this is because launchd handles setting the stdout and stderr paths to this file, and by the time my scripts can get around to removing it, the file is already open. Finally, when you activate the script, you must remember to set the DISPLAY variable in launchd's environment (launchctl setenv DISPLAY "$DISPLAY").
By the way, I still want to make my box into a buildslave. Though now I'm thinking about making my old MacBook Pro into a slave, instead of my Mac Pro which gets used a lot nowadays.
Chip
Cheers,
Jeremy
-
Charles Davis -
Dan Kegel -
Jeremy White