One of the things I learned when I first started at Mozilla a little over a year ago is that there’s this kind-of unwritten ‘rite of passage’, so to speak. If you want to be a developer, one of the first things you have to do is learn to build Mozilla. I, like many others at Mozilla, have contributed to open source projects in the past, and so we expect the effort it takes to get the product built. Not everyone is so lucky, and it’s definitely possible to lack patience when trying to join an organization to which you’re donating your time. Building Mozilla can be intricate, tricky, and downright frustrating. Even if you get it the first time, there are a lot of long commands (at least on linux) you have to remember and keep track of in order to rebuild the software.
If you don’t believe me, or you want to give it a try (please do – it’s always great to have people who can think about our processes and make them better!), take a look at our simple build documentation:
You might now be asking, ‘How does anyone do this every day?’ Well, that’s where the unwritten rite of passage comes into play – most developers, in their early days with the organization, spend a great deal of time developing a set of automated scripts, designed to ease the burden of all of these commands, and to customize the build system to their workflow. If you do it correctly, you can spend anywhere from few days to a few weeks creating these scripts, and then only spend a few minutes every so often, polishing them and updating them.
This works great for the ambitious and eager script-writer. But, keep in mind that these scripts are written, and this trial by fire is passed, before a contributor can even begin working on a real problem. Not only that, but because our organization is made up of so many different kinds of people – non-platform developers, UX experts, artists/creative folks, add-on developers, test engineers, build engineers, automation engineers… (the list goes on) – not everyone has the skill or patience to understand arcane build output.
I’ve found that new contributors are excited to get working on a problem with Firefox. Unfortunately, if it takes them an entire week or more (I’m not talking build time here… I mean actually fiddling with .mozconfig files, Makefiles, directory structures, etc…), they end up getting burned out before they even begin their project! I’d really like to avoid having contributors quit before they even get to the heart of the problem they originally signed up to take on.
So, to that end, I decided to take the scripts I originally used to make building Mozilla a bit easier and more customized for me and open them up to the general public. I call the set of tools ‘JMozTools’, and they are available at http://www.glasstowerstudios.com/trac/JMozTools/ These tools are not designed to replace the set of build tools already existing in Mozilla; they are designed to provide a set of ‘shortcuts’ for common build and run commands that would otherwise sometimes get unwieldy.
As time goes on, I intend to add some other tools to the suite, as well, such as Eclipse plugins that assist in merging those irritating .rej files that sometimes persist after running hg update and hg qpush’ing a bitrotted patch. For now, all of the scripts that I use on a regular basis (everyday – literally) are in this suite. Installation and use documentation is on the trac site, as are current bug reports and roadmaps for the future of the toolset. I encourage you to contact me if you have any questions about how to use the scripts, or especially if you’d like to contribute to this mini-project.
Happy (Mozilla) Hacking!