The reason you want to generate make files is that with make you are specifying every single goal, its dependencies, etc. (I am ignoring pattern rules).

But for many projects this is redundant, e.g. I have one project with a lot of libraries and to “build” a library all that matters is that:

1. It is a library (as opposed to an application).
2. Which sources it is built from.
3. What it should be linked with.
4. Potential resources (making it a framework, if any).
5. Potential unit tests.

As for #2 and #5 I probably want to specify that as simple globs (e.g. src/*.cc).

Providing the above information can be done fairly simple and a make file can then be generated from that information — so that is the motivation for generating make files, i.e. find the best abstraction for what you want to specify, then use make more or less as an implementation detail, as make is a very good engine for carrying out the actual build and with some clever setup, you can make it appear as you only interact with one system (make) which will automatically rebuild make files when required.

So generating a rake file would only be if you feel that rake is not a good way to express your current tasks, but if that is the case, I would argue you’re much better off then generating make files, unless you want ruby in your new abstraction (which I personally would strongly discourage as it should be kept declarative if at all possible).

I don't want to discredit Makefiles. I like make as a simple and very portable build tool. That's especially true for build processes involving a lot of small non-repeated scripts. While you can include scripts in your build process with Xcode, it's more tiresome to edit and manage through the GUI than with a plain old Makefile.

I look forward reading your next parts, especially the one about auto-generating Makefiles.

That said, I still think it will be an unwieldy exercise since the application and the framework are two different (Xcode) targets and we want the application to depend on the unit test, and the unit test to depend on the framework.

What you will end up with is Xcode’s answer to the problem of extensibility: “custom shell script target” which will run every single time you re-build your target, regardless of whether or not there actually is a need for it.

Actually, that's not true. If you set the dependencies of your script by filling the input files and output files line below the script field, Xcode will run the script only when the output files are outdated. It works pretty much like in a Makefile.

If this doesn't work for you then you're probably setting the paths wrong.

Basically the benefit with make is that it is a system for linking actions together and have make figure out when it is time to run which actions. The actions to run can be anything.

I realize that calling these posts ‘Build Automation’ is probably a misnomer, because what this really is about is automation. Building projects I will talk about in part 4. Make itself is not a good abstraction for building projects when we know the domain but it is still a very good engine. So comparing gyp to make is akin to comparing an abstraction to an engine (although make itself offers an abstraction to the lower-level task of executing interdependent actions).

As for gyp itself as a good abstraction for building projects: I don’t think so ;)

I'm curious about what you mean about the number of variables not being fixed. Doesn't that imply that you are using a loop of some sort? Or do you mean that the example was a trimmed-down version of something more complicated in the real code?