If you pass
--enable-chrome-format=symlink in as an option to configure, any chrome files that don’t need to be preprocessed are symlinked instead1. This is really useful because it allows for a much quicker edit-test cycle – you don’t need to run
make every time you edit a file. However, the option only works on platforms that have historically supported symlinks, i.e. Mac and Linux.
… until now. I checked in a patch to the build-system repository yesterday adding support for the option on Windows. Instead of symlinks, though, the option creates hard links2. This isn’t a big deal: the edit-test cycle is as quick as it would be with symlinks.
mozilla-central is in lockdown mode right now, so the patch will only be merged into it after it branches for Firefox 4. You don’t need to wait, though – grab the patch from bug 634596 and apply it to your tree.
- Your source and object directories need to be on the same NTFS partition.
- If you use an editor that breaks hard links by default, you will need to configure it to not do so. For Emacs, add the line
(setq backup-by-copying-when-linked t)to your .emacs.
1 Yet another reason preprocessed chrome files suck.
2 Why? Firstly, symlinks aren’t supported on Windows XP or 2003. Secondly, even though they are supported on Windows Vista and 7, creating them requires you to be an elevated administrator. Even if you grant yourself the required SeCreateSymbolicLinkPrivilege, if you’re an administrator UAC takes it away.