Being able to quickly and easily build team projects on a newly imaged PC is a development process necessity: A new team member, with not a whit of project knowledge beyond where to find the simple build instructions, should be able to follow a sequence of clearly documented steps — automated where possible — painlessly generating a build.
No unnecessary mapped drives and hard-coded UNC locations. No undocumented but necessary third-party tools at hard-coded locations. No byzantine by-hand registrations and muddifications.
This holds true for open source projects as well. While a grizzled kernel hacker obviously doesn’t need hand-holding, they didn’t start as a grizzled kernel hacker. At some point they were new to the code, and the number of obstacles they faced in those early days were probably significant indicators of the likelihood that they would stick with it, overcoming administrative type nuisances and getting to the point where they were actually working on the code itself.
Some may see the barrier to entry that often exists as a useful filter, only letting only the best of the best through, but that contention seems dubious. More likely an onerous getting-started process simply demotivates a lot of great talents from even bothering. Being an expert C++ developer doesn’t mean that one wants to spend a day messing around with cygwin packages and dependencies, setting up countless poorly or incorrectly documented environment variables and configurations.
On this theme, I recently took a look at the state of the bleeding edge of Firefox — I think Firefox 3 is going to be one of the most important applications in years, and is going to completely redefine the entire industry — and was very pleasantly surprized to find how stunningly gorgeous the build process now is for a Visual Studio-using-Windows developer.
-Run the appropriate start-msvc batch file (e.g. start-msvc8.bat for Visual Studio 2005 users). I updated mine to set the CL environment variable the compilation flags that I wanted, as opposed to passing them on the –enable-optimize parameter of the .mozconfig file).
-In the appropriate location — / is fine, given that it’s actually in the msys subdirectory and not really at the root, get the client.mk file via the following trivial command.
cvs -d :pserver:firstname.lastname@example.org:/cvsroot co mozilla/client.mk
-Navigate into that folder
-Do a CVS get of the appropriate project (originally I was getting the source outside of the make script using the excellent TortoiseCVS, however it turns out that you can’t just wholesale grab the tree, and should stick to the integrated CVS functionality).
make -f client.mk checkout MOZ_CO_PROJECT=browser
–Configure an appropriate /mozilla/.mozconfig file (note that Windows will block setting that filename directly. Do a mv move command in the MINGW32 shell after saving from notepad or wherever. You’ll likely just copy the block on the linked page for the appropriate project, however if you’re adventurous you might try out the configurator tool).
make -f client.mk build MOZ_CO_PROJECT=browser
This is the slickest, most painless process for such a large scale application that I’ve ever seen. I can just re-checkout and build daily if I’d like to be on the razor edge, though sometimes that will mean a broken build.
Now I’m running an ultra-optimized, stack-protected custom build of Firefox 3.
Brilliant. Absolutely brilliant. Now I just have to find a way to put some obnoxious exhaust pipes on this bad boy.