sharing one Mozilla source tree with Linux/WinXP VMs on Mac host OS

Here’s how I shared one Mozilla source tree on my Mac OS X host OS (one Core 2 Duo, 4GB physical RAM) with two VMware Fusion VMs, one running Ubuntu Linux 8.04 (two CPUs, 1GB RAM), the other running Windows XP (one CPU, 512MB RAM):

I checked out the source tree to ~/Mozilla/source on my Mac’s filesystem.

I configured each VM with one shared folder via Fusion’s Virtual Machine > Shared Folders > Shared Folder Settings… configuration dialog. In both cases, I shared my Mac user account’s home folder (/Users/myk). Fusion 2 named both shares myk (Fusion 1 had named the Windows share myk On My Mac).

I made these shares read/write so I could manipulate the tree from the VMs (particularly from the Linux one, where I do most of my development) and also because the Mozilla build process tries to modify the source tree, even when you’re using an objdir (f.e. bug 384978), and the build process runs smoother if you let it.

On Linux, the shared folder showed up at /mnt/hgfs/myk. Because of a limitation in Fusion (described in the release notes as “Shared Folders permissions might be too restrictive in Linux and Mac OS X Server guests”), I had to configure the /etc/fstab entry for the shared folder to mount with my Linux user account’s uid/gid:

# Beginning of the block added by the VMware software
.host:/   /mnt/hgfs   vmhgfs   defaults,ttl=5,uid=myk,gid=myk   0 0
# End of the block added by the VMware software

Note: this modification gets reset and has to be redone every time I reinstall VMWare Tools (i.e. after each kernel upgrade).

On Windows, the shared folder showed up at Start > My Network Places > Shared Folders on .host. Fusion 2 automatically created a network drive for the shared folder, mapping it to the uppercase drive letter Z:. When I was using Fusion 1, I manually created the network drive via Tools > Map Network Drive in Windows Explorer.

In older build environments, I then had to create /etc/fstab (following the instructions in /etc/fstab.sample) to mount the network drive, but I think simply mapping the drive automagically makes it available at its lowercase Unixy equivalent (f.e. /z) in the latest versions of MozillaBuild (perhaps after a MozillaBuild or Windows restart?).

I only share my source tree, putting config files in ~/Mozilla/configs and builds in ~/Mozilla/builds on the Mac and Linux filesystems and in /home/myk/Mozilla/(configs|builds) on the Windows filesystem (as my home directory on Windows is /c/Documents and Settings/myk, and Mozilla has trouble building to a directory with spaces in its path).

Once configured as described, building on each OS became the simple matter of crafting the build config file, changing to the source directory, and calling make, for example on Linux (with this config file):

cd /mnt/hgfs/myk/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

On Mac (with this config file):

cd ~/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

And on Windows (with this config file):

cd /z/myk/Mozilla/source
time MOZCONFIG=/home/myk/Mozilla/configs/minefield-opt make -f client.mk build

Note: compiling on Linux seems pretty speedy, but compiling on Windows is dog slow, perhaps even slower in Fusion 2 than in 1. I haven’t tried it lately, but it might be faster to share the tree with Windows using SMB.

Note: it’s theoretically possible to compile on two or all three OSes simultaneously, but it does slow down the machine, and I got build failures the few times I tried it (I don’t remember exactly what now, I think something about the Windows build process being unable to access certain files).