Organizing build trees

Wednesday 31 August 2005This is close to 18 years old. Be careful.

I’ve got a pet peeve about the way build trees are organized: I like to segregate source files from build files. For example, the ideal tree would have a src directory that had all the source, an obj directory that had all the intermediate built files (for example, .obj files), and a bin directory that had all the finished built files (.exe, .dll, .pdb, .map, and so on). I think there are a number of benefits to this organization:

  • If I want to clean out the built stuff, I just delete the bin and obj directories. Simple.
  • If a build fails, I can compare the bin and/or obj directories to a previous successful build to get an overview of what finished and what didn’t. Simple.
  • If I want to make a copy of just the human-produced files, I know where they are (src). If I want to save off the finished executables, I know where they are (bin). Simple.

It can be kind of a pain organizing things in this way, but I think the benefits outweigh the costs. Usually, it’s only a matter of setting up a project properly at the start, there’s no maintenance required.

Unfortunately, Visual Studio .NET doesn’t let me organize things this way for C# projects. There’s an option for where to put the bin stuff, but the .obj files have to go into a subdirectory of the project directory. Why? Grrrr, submit to the borg!


As an added bonus to this tree organization, you can build for multiple architectures in the same source tree without stepping on any toes. Just subdivide obj into obj/Linux_x86, obj/Solaris_sparc, obj/Darwin_ppc, etc. I find this very useful for building software that will run on heterogenous clusters. (Which is more common now that I have AMD64 mixed with x86.)
You want to hear about bad build trees? We inherited a codebase where each project of the source code is in a separate branch, so that in order to make a new branch of the product, you actually have to make like 10 new branches. In addition, each branch is under the same directory as its peers, so you have something like this




Some projects include stuff from other projects, which of course would be impossible using this asinine scheme, so each project has a post build step where they copy the pertinent .h and .lib files to ../Current, and then everything can just #include from [projectname]/Current

I swear these people were insane. This is using Perforce, btw, and I think is one of the contributing factors to why my company dislikes Perforce.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.