TIGSource Forums

Would this be stupid?

if a person is stupid in the woods, are they a stupid person?

I... yes, tautologically?

About any (meta-)build configuration tool (CMake, Autotool, Premake, Scons, etc.)

It should be used if:

 1. you have time to use it (aka not in game jams)
 2. you master basics of it (aka not just when you discover it : use experimentation projects first with those)
 3. you need to be cross-platform (aka most of the time those days, but you might want to not bother on windows for example, making visual studio projects easier to use anyway)
 4. you don't mind separating project definition from your favorite IDE (aka you don't mind having to add new files paths to an external text file not managed by your IDE).

If you're in those cases, then go for it. Just check wich tool you're most confortable with.

For example, I'm using CMake for a gui tool project, mostly becasue it allows simple integration of Qt. But I hate some CMake features so I'm not sure if I would use it for a game, even if it's the most complete tool for builds.

I'm planning to try Premake because it seems to be a good tool in case of games. Not mature yet they say, but very flexible and uses lua to define everything.

Autoconf is really about distribution, and I'm assuming a personal project isn't being distributed, otherwise it wouldn't be personal.

Using autoconf for something like this would be pretty dumb, I think.

I often wished I used it since I tend to move between mac/ubuntu/debian/freebsd and some projects ended up messes of hardcoded makefiles that might or might not run one day on one machine.

Also by using it you get experienced with it for the time you Really need it.

I haven't set up an autoconf project myself, but having built a large number of libraries that use it, I feel like it usually hinders me more than it helps. In many cases, it would configure things in such a way that the output runs fine on my computer, but nowhere else. Rarely if ever is support included for multiple-architecture builds on Mac OS X or cross-compiling for iOS, so I have to figure out all the variables I need to change to get those things to work. MinGW is frequently problematic too. Sometimes I have no choice but to modify configure itself to get it to do what I want. However, it's quite possible that these problems are a result of how the project was set up, not the tool itself.

What I've always preferred is projects that include a separate makefile for each platform/build system. Maybe these can even be generated by autoconf, but they really save me a lot of headache. Now, if the autoconf project is something that would only ever need to run on the computer that built it and never be distributed in binary form, I'm perfectly happy with it, but I find this rarely to be the case.

CMake is really really nice. I use it for painless cross-platform building (gcc/Make on Linux and Visual Studio 2010 on Windows)

This. CMake is awesomes.

It's awesome for simple projects.


Add multiple (required by the domain) dependencies and sub projects and it can become hell.


But it's manageable.


But it don't (really) provide relative paths (AND THAT IS NECESSARY.).