Vista Building with VC9

If you’ve been banging your head trying to build Firefox on Vista with the newest Visual Studio 2008 express edition (VC9) – know that it is possible now, and with minimal bruising of your forehead.

Two things you need to remember:

1. You have to run start-msvc9 in mozilla-build as administrator (if you do not your builds will fail with messages about bad file numbers and such)

2. You have to put the following four lines in your .mozconfig (for now – keep your eye out for a new rev of mozilla-build which should fix – current at 1.2)

ac_add_options --disable-xpconnect-idispatch
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-accessibility

That’s it – after bug 419665 is checked in, there should be no other obvious issues unless you forget to run as administrator or check out when the tree is burning.

Happy Vista building.

Clobbering buildbot run leaves no trace of history

Sadly, in my excitement to get a Mac buildbot slave up and running yesterday, I have overwritten my profile with a lot of file:/// addresses in the awesomebar and little else. The fabulous part of searching in the awesomebar is so much less when you have NO history.

This is because the master.cfg is set up to clobber and thus wipes clean the default profile as it does it’s thing. Not so bad for a VM unittesting machine, kind of terrible for a human with poor retention for URLS thanks to a dependence on the awesomebar.

/me writes on the board “Never use the default profile” * 1000

Week [1] – Learning to set up Buildbot

Okay, it’s time for another update as to my activities in MV.

By the time Robcee left last Friday to go back to the picturesque province of New Brunswick, I had come pretty close to having Buildbot installed and ready to be deployed on my CentOS VM.

Today in between wrestling with trying to build on Vista with VC9 (I must remember to “run as administrator” on the mozilla-build shell) I have been learning to deploy my own local buildbot master and a linux slave.

In getting to this:

there were a couple of roadblocks.

1. The current master.cfg and mozbuild.py are written for Builbot 0.7.5 and so I had to make a couple of small changes as per the documentation to account for import changes (no more step, using steps.shell or just steps instead) and also html.Waterfall is deprecated we should use html.WebStatus now.

2. It took a little while to figure out that the “force build” option that you can get when you click on a slave’s name link in the waterfall is actually an option passed in to html.Waterfall as in html.Waterfall(http_port=2005, allowForce=”true”) and this gives you a nice little html form where you can force a build as you need one.

3. The last little glitch was just making sure that all the names matched up. The major lesson learned here was: Never follow directions. Just because someone says to do


buildbot create-slave slave localhost:9989 linux mozilla

doesn’t mean that will work. You have to look beyond the literal instructions and realize that the slave name must match what is in auth.py and same with the password.

Next goal – learn how to kick unittest machines when they misbehave.