top | item 8556094

(no title)

dlundqvist | 11 years ago

This is similar to what I wrote at work on and off over the last couple of months, replacing a build system using recursive Makefiles. Due to the way our product is composed I ended up adding support for building static libraries, programs, RPMs and documentation. With full support for dependencies, meaning if a source for a library is changed, the library will be rebuilt, programs that links against it will be re-linked, if the program is part of a RPM it will be rebuilt etc. Documentation will also be rebuilt if source embeds documentation. Another great bonus is of course that with one GNU Make instance and proper modeling of dependencies "make -j" works great, every time. I guess we have a couple of hundred source source files and "make -j" will happily start compiling them all. Read Peter Millers paper about recursive Makefiles about why the above is preferred.

Makefiles are of course a bit limited compared to shell scripts, but you can do a lot with implicit rules, static pattern rules, second expansion, call and eval, etc.

discuss

order

mkpankov|11 years ago

I ended up using $(eval ...) a lot, and turns out Make's support for it is... suboptimal.

As for paper - I believe it's "Recursive Make Considered Harmful" - I read it, it's great. Was one of the main motivators during build system rewrite.

dlundqvist|11 years ago

Three or four levels down in $(eval ...) and $(call ...) still makes me stop and think how many $ I should have.

Yes, that's the paper, I was also heavily motivated by it. And when I read JDK also switched[1] to something similar, it just cemented my belief it was the right way to go, for the same reasons as for them.

[1] - http://openjdk.java.net/jeps/138