Comments on: Build Systems (For small to medium-ish projects) +1 for premake. I also like JAM ( The only build tool I <em>like</em> is Apache Ant: portable, with a straightforward data and execution model, not second-guessing the developer, compatible with arbitrary command-line tools, and easily extensible should the need arise. Build scripts are somewhat verbose (XML with substitution variables) and hard to write well, but it's a price I'm more than willing to pay to have a tool that does exactly what I want. The only build tool I like is Apache Ant: portable, with a straightforward data and execution model, not second-guessing the developer, compatible with arbitrary command-line tools, and easily extensible should the need arise.
Build scripts are somewhat verbose (XML with substitution variables) and hard to write well, but it’s a price I’m more than willing to pay to have a tool that does exactly what I want.

]]>
By: Wladimir/2011/05/25/build-systems-for-small-ish-projects/#comment-4859 Wladimir Wed, 25 May 2011 15:08:30 +0000 It's good to see scons getting some attention. I reckon it's pretty good. Another alternative I've haven't looked into yet is waf. It's used to build Samba and NodeJS projects. http://code.google.com/p/waf/ It’s good to see scons getting some attention. I reckon it’s pretty good. Another alternative I’ve haven’t looked into yet is waf. It’s used to build Samba and NodeJS projects.

The best build system will always be "the one you're currently using" because switching build systems takes a ton of effort. I use GNU make currently, with some custom extensions. It's perfectly capable but if I was going to start a new project this is my rather short build system must-have list: - Integrated tightly with a well-supported scripting language. (Perl, python, ruby, lua, all count.) - Able to generate VS build files... because there's sane way to use Visual Studio's build management tools. GNU make falls down in these two areas, and while they aren't huge deficiencies I do like the direction newer systems are taking. The best build system will always be “the one you’re currently using” because switching build systems takes a ton of effort. I use GNU make currently, with some custom extensions. It’s perfectly capable but if I was going to start a new project this is my rather short build system must-have list:

- Integrated tightly with a well-supported scripting language. (Perl, python, ruby, lua, all count.)
- Able to generate VS build files… because there’s sane way to use Visual Studio’s build management tools.

GNU make falls down in these two areas, and while they aren’t huge deficiencies I do like the direction newer systems are taking.

]]>
By: Jim/2011/05/25/build-systems-for-small-ish-projects/#comment-4843 Jim Wed, 25 May 2011 09:49:37 +0000 I definitely don't use a whole GNU environment -- in fact, the only executables I use are gcc/clang and binutils (ar/ld/etc). I can possibly understand the use of sed to rewrite dependencies, but that's honestly about it. If your makefiles have call out to use bash or awk, it sounds like you're going about it the wrong way. :) I definitely don’t use a whole GNU environment — in fact, the only executables I use are gcc/clang and binutils (ar/ld/etc). I can possibly understand the use of sed to rewrite dependencies, but that’s honestly about it.

If your makefiles have call out to use bash or awk, it sounds like you’re going about it the wrong way. :)

]]>
By: nicolas/2011/05/25/build-systems-for-small-ish-projects/#comment-4837 nicolas Wed, 25 May 2011 07:10:26 +0000 I went through something similar a few months ago, and ended up sticking with GNU make. In my opinion, it is the best for handling multiple platform development, and it's really not all that difficult once you get used to the syntax. :) Also, you can avoid recursively calling make by utilizing the $(MAKECMDGOALS) variable, which contains a space-separated string of the goals that you pass on the command line. I posted a <a href="http://stackoverflow.com/questions/4069515/bug-in-gnu-make-target-specific-variables-are-not-expanded-in-implicit-rules" rel="nofollow">somewhat related question</a> on StackOverflow, as I wanted the .obj files to be in a separate build directory for debug and release targets, and I found I could only do variable expansion (for the build path) when using that variable. I went through something similar a few months ago, and ended up sticking with GNU make. In my opinion, it is the best for handling multiple platform development, and it’s really not all that difficult once you get used to the syntax. :)

Also, you can avoid recursively calling make by utilizing the $(MAKECMDGOALS) variable, which contains a space-separated string of the goals that you pass on the command line. I posted a somewhat related question on StackOverflow, as I wanted the .obj files to be in a separate build directory for debug and release targets, and I found I could only do variable expansion (for the build path) when using that variable.

]]> By: Erwin Coumans/2011/05/25/build-systems-for-small-ish-projects/#comment-4828 Erwin Coumans Wed, 25 May 2011 03:07:23 +0000

]]>