Question

I have been crafting a makefile for a while now. It supports easy creation of exe, lib and dll type projects, through the use of includes.

Now that I have started using mercurial again, I notice that everything is nice and clean until I do a build. You see I have my object files going into sub directories below the source directory for each sub-project. And I have my lib, exe, and dll files being built to directories which are below the main working directory. This means whenever I do hg status, it will list these temporary binary files with ‘?’, which is visual clutter I don’t want. (It’s not mercurial’s fault and of course I wouldn’t be so naive to check them in to the repo or anything like that.) I only want hg status to uncover files that I may have forgot to add properly, not these temporary built ones.

The current dir structure is like this:

projroot
-- subproj1 (for source files)
-- subproj1/intr  (for object files, release build)
-- subproj2 (for source files)
-- subproj2/intr  (for object files, release build)
-- bin (for exes and dlls)
-- lib (for libraries that I build)

So I’m thinking of restructuring the makefile to keep the files that are built (objs libs dlls and exes) outside the working directory. Do most people keep all the binaries in a directory one level above projroot to avoid SCM seeing them? There must be some best practice. What I was using seemed good but it’s a bit dated I think, certainly since I have seen ant’s way of having a completely seperate tree for Java src and classes.

What about this structure?

projroot (contains common makefile includes and repo in here)
-- subproj1 (for source files)
-- subproj2 (for source files)
build
-- subproj1/intr (.o / .obj files in release build)
-- subproj1/intd
-- subproj2/intr
-- subproj2/intd
-- lib (all built libs)
-- bin (all built exes and DLLs)

The build directory is outside of the working directory and so is ignored by whatever SCM we would use.

Your answer has to take into account the common makefile source code in projroot and the fact that there are multiple projects, each with their own collection of built binaries which you may possibly want to distribute seperately.

Answer 1

Personally I prefer such a directory structure as I don’t like any of the source subfolders to be polluted with compiled intermediate files. Doing a clean is just a matter of deleting the output folder

projroot
-- subproj1 (for source files)
-- subproj2 (for source files)
-- output/bin (for exes and dlls)
-- output/lib (for libraries that I build)
-- output/subproj1/ ( for *.o files )
-- output/subproj2/ ( for *.o files )

This has the added benefit that I can set the whole of output folder to be ignored by the source control management and I don’t have to to check the SCM software to see what files are generated and what are revision controlled.