So I’m getting into the swing of things here at work. It’s a pretty nice place to work — the people are relaxed and friendly, and charmingly cynical about their absentee managment. The code is innovative and of good quality.
But the build system. Oy.
Is it merely a pipe dream of mine to eventually find a place where setting up one’s build environment consists of one checkout, and the head branch — if the source control system is capable of branching at all — is always in a buildable state? These things can be made company policy, you know!
But no, the build master is a secretive gnome who’s never around. Checking out the source requires mapping a double dozen directories to random places in your working copy. There is a common include directory that has CPP files in it that are compiled multiple times in different projects. There are binaries in the source code repository. The Visual Studio project settings are massively inconsistent between projects and configurations. There exist multiple massive contradictory documents on the process, but building the system requires multiple tweaks.
I’ve done this twice now, the first time last week with the crap machine I had at first, and now the last two days on my good machine. It takes two days on a fast machine to set up and build the initial development environment. Oh well, it means I can read more blogs…
Here’s some policies for a sane and problem-free build system:
- Use a source control system that supports branching. Perforce, Vault, Subversion, etc. NOT VSS. (Caveat: I haven’t tried the new VSS yet, but the old one is clearly from the hot place.)
- The directory structure of the repository should mirror the structure of the working copy. You’d think this would be a no-brainer. The people who “designed” VSS’s “set working directory” functionality must have been smoking something powerful.
- Checkins to the head branch must always build. Breaking the head build must be an officially reprimandable offense. This can be enforced in software, with a decent source control system.
- Keep Visual Studio project configuration standardized across configurations. This means you have to learn about $(OutDir), $(TargetFileName) and friends. NEVER hard-code a directory in a project configuration except the initial output directory setting.
- Keep VS project configuration standardized across projects. If all the binaries are going in one directory, point $(OutDir) at that directory in all projects. Don’t have batch files copying things around in some projects.
- Binaries never go in the repository, unless they’re third-party software needed to build.
- Make sure the entire thing can be versioned, configured, tagged, built and packaged with one click. Now schedule it for every night, and burn the resulting source and package to a CD. This way you’ll have a consistent record of development.
For more excellent advice, see Mike Gunderloy’s excellent Coder To Developer. If there’s one software book you buy this year, make this the one.