Using make: builds

[GBGames]

I've gotten used to the way make works. I use g++ and can build executables and object files just fine.

If anyone has any advice on how they actually use make in their real life projects, I'd appreciate it.

Basically here is how I have my project directory setup:

Project_Directory
- source
- images
- documentation
- build

My main plan is that the source files will get compiled and the executable will be placed in build, preferably in binary and tar.gz form.

Is it normal to have your source directory littered with the object files when you run make? What I mean is if I have three source files, main.cpp, class1.cpp, and class2.cpp, is it normal for most projects to basically have the source directory have those three files as well as the object files that would be created when make is run? Or is there a different directory you would send those to?

Also, since build is a different directory than source, I know the make target would for the executable game.exe looks like:

../build/game.exe: main.o class1.o class2.o

However, no example I've seen has targets from different directories. Is there a different, preferred "best practice" for this?

Thanks in advance for the help.

[BlueSky]

A lot of your layout will be based on personal preference and what your needs are.

I would put your object files somewhere other than the source area if you plan on switching configurations quite a bit (release, debug, etc..). I would probably put the exe in with the objects, then copy it down the directory tree so its always in reliable place, independent of your last make configuration.

It takes more work, but its worth it when it works, and it sounds like you're up to the task anyway.

If you have a simple project and don't mind a little cludder it then you can save a lot of time and effort by having a big directory that has everything in it. That can be suprisingly efficient for some tasks (e.g. grepping for a symbol in every file of the project).

[GBGames]

The more I flesh it out the more I see that I haven't thought quite enough about it.

My plan is to make games for Windows, Mac, and Linux, so it would make sense to organize the object files for each platform in their own directories, as well as the release/debug builds for each platform in separate subdirectories of build.

[ggambett]

I don't use Makefiles anymore but I follow a similar idea. My Betty's Beer Bar tree looks like this :

bbb
+- resources
| +- common
| +- imagesrc
+- src
| +- obj.linux.debug
| +- obj.win32.demo
| +- obj.win32.full
+- dist
| +- linux.debug
| +- win32.demo
| +- win32.full
+- libs
+- win32
The 24 bit, uncompressed, uncropped images start in /resources/common/imagesrc. A build script crops and converts them, placing the resulting images in /resources/common. A build script there packs them in a resource file, common.dat, which ends up in /resources.

Then, the src script runs, placing the objects files in the corresponding "target" directory. The binary is also in that directory.

Finally, the dist script runs, which symlinks the resources, the binary, and the platform-dependent lib in the corresponding dist branch.

As you can see, the tree is traversed in post-order (children first, then self). This allows to do quite complex processes in separate steps (such as crop the images, then tile them together, then convert them to another format)

The general idea is to keep redundancy at a minimum, and to always have the dist branches ready to zip and upload.

[FlySim]

A little off topic, but I use CMake for my cross platform projects - highly recommend it. http://www.cmake.org

-J.R.

[keethrus]

I thoroughly follow the mindset of keeping things simple. I create two batch file for each project, one compiles everything, and the other links everything. It's quick and simple for me anyway! :)

- Jeremiah

[Sillysoft]

I use apache ant (http://ant.apache.org/) as my cross-platform build tool. I have a similar setup to what you guys have described. I would keep all your object files out side of your source dir. All my files get thrown into the build dir during compiles. I also have my installer creation inside ant, and that grabs all finished components from the build dir, does the installer mojo on them and puts the finished files into a dist folder. Only a few files get created in dist, so it's nice and clean. All sorts of wacky stuff gets created inside the build folder, normally I don't go in their much.

[Rainer Deyke]

Interesting... I thought ant was Java only?

I use Boost.Build. It has its drawbacks (mainly poor documentation and high complexity), but when it works, it works great.

[GBGames]

Interesting... I thought ant was Java only?

I think ant is a tool that is heavily used with Java but it can be used with anything, similar to make.

EDIT: Er, similar to make, but with a lot of functionality that makes it superior in many ways. Downside is the complexity of creating the xml file whereas a Makefile is pretty easy to make.

[Bluecat]

ANT is part of the Apache project I believe. There is also a NANT. I'm not sure but I think that is written in C#.

I've used ANT before. It beats using an old style makefile hands down.

[Jim Buck]

I just use DevStudio .NET to do my building. A team I work closely with here, though, uses SCons.

[Aldacron]

A team I work closely with here, though, uses SCons.

I recently started using SCons and love it. I had a fairly complex system of makefiles that was a pain to modify. SCons greatly simplifies it.

[mahlzeit]

Another option: jam (http://www.perforce.com/jam/jam.html). We use it to build the Haiku (http://haiku-os.org) source tree, which is almost 5 million lines of code big.

[princec]

I use Ant too. It truly is wonderful compared to make.

Cas :)

[Jim Buck]

The SCons team started out using jam but moved onto SCons when it better suited their needs. Yeah, it has a very cool caching system which is awesome in a multi-person environment (as long as you have an intranet). The only downside is that is can often take up so much memory that it will end up taking some types of builds a crazy amount of time to run. The team using SCons have 1GB RAM machines but had to upgrade to 2GB in order to combat this problem.

[Rainer Deyke]

Actually Boost.Build is also based on jam, with a lot of enhancements.