CODEWITHSUNDEEP
c++version-controlmercurialbuildmakefile
ScrollerBlaster
ScrollerBlaster

Reputation: 1598

What is the best dir structure for building obj and exe files?

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.

Upvotes: 2

Views: 260

Answers (3)

Matthieu M.
Matthieu M.

Reputation: 300329

Since you already have the Makefile overhaul answer, I'll submit a mercurial answer.

You can simply teach Mercurial to ignore some files, and you can easily do so by pattern:

// .hgignore file
syntax: glob

# Object Files
**/intr/

# Libraries
lib/

# Binaries
bin/

Quick and dirty, as we like.

On the other hand, I find rearranging the Makefile to have a single polluted dir better than keeping all the generated files scattered to the wind.

Upvotes: 3

parapura rajkumar
parapura rajkumar

Reputation: 24413

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.

Upvotes: 6

Michael Kristofik
Michael Kristofik

Reputation: 35208

Couldn't you just set up your .hgignore file to hide the binaries from hg status? That seems far simpler than rearranging your entire project tree.

Mercurial will look for a file named .hgignore in the root of your repository which contains a set of glob patterns and regular expressions to ignore in file paths.

Upvotes: 2

Related Questions