Organizing build trees

Wednesday 31 August 2005

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!

Comments

[gravatar]
Stan Seibert 9:47 AM on 31 Aug 2005

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.)

[gravatar]
Nate Finch 11:35 AM on 1 Sep 2005

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

RootProductFolder
---Project1
------Project1.V1
------Project1.V2
------Current

---Project2
------Project2.V1
------Project2.V2
------Current

etc.

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:

name
email
Ignore this:
not displayed and no spam.
Leave this empty:
www
not searched.
 
Name and either email or www are required.
Don't put anything here:
Leave this empty:
URLs auto-link and some tags are allowed: <a><b><i><p><br><pre>.