4 ms·
Replacing make with python is a huge step back. The makefile language is simple yet extremely powerful for describing a dependency tree such as that for buildi
by mansr 13y ago
Replacing make with python is a huge step back. The makefile language is simple yet extremely powerful for describing a dependency tree such as that for building an executable from sources. Its perhaps strongest point is that it completely agnostic to what the different steps actually do rather than consist of a predefined set of canned rules/tasks with, if you're lucky, a convoluted way of adding your own using e.g. python (or worse, java). This means that as long as a shell command can turn a set of inputs into an output, describing it takes (usually) just two lines of makefile, one naming the target and prerequisites, one providing the command to perform the transformation. If a particular rule is too complicated for a few shell commands, invoking a separate script (or even a just-built executable) is trivial. Every other system I've looked at needed a comparatively enormous amount of code for adding even the slightest tweak to the built-in rules.
GNU make is actually two different languages coexisting in the same file (the makefile), a declarative language for describing the targets and their dependencies as well as a functional language for the variables/macros. Once you realise this, a whole new world of possibilities opens up. If more people took the time to actually understand proper use of makefiles, perhaps we'd see fewer poorly reinvented wheels.
- mkesper 13y agoDo you have some link to a good tutorial/guide showing those possibilities?
- mansr 13y agoThe official manual is mostly easy to understand. There are various 3rd-party books available, but I haven't read any of them.
- rkangel 13y agoI've written a few complex Make based portable build systems over the years and in my experience Make script is its major limitation. Make is a great system for declaring dependencies - the basic syntax is wonderfully concise (not that that's everything) and clear, and the system is a great platform on which you can build your build system (unlike Scons which tries to abstract away all sorts of things and just ends up hiding them). The problem is that when you are trying to do anything more complicated than simple rules you are lacking basic language features. You don't even get function calls - the templates work under many circumstances, but not all (and are a pain to debug). Also don't get me started on invisible syntax errors (tabs vs spaces), and the only error message Make has' Missing separator. Stop'. Writing a build system in Python loses you that concise declaration syntax (but again characters typed isn't everything, as long as you maintain clarity it doesn't matter), but gets you ugh more flexibility to produce rules under complex circumstances, which saw at you need for portability.
- mansr 13y agoYour comment betrays your ignorance. Firstly, you call it "make script," suggesting that you view makefiles as a typical (procedural) script that is executed from top to bottom. I base this on my experiences working closely with others who also used the term "make script," all of whom suffered from this misconception. Secondly, GNU make does have function calls. Look up the $(call ...) construct. When the built-in functionality is insufficient (and of course such cases come up), it is trivial to call an external script, written in your language of choice, using either the $(shell ...) syntax or as part of a target recipe. As for the "Missing separator. Stop." it is not fair to dismiss an entire tool because of one slightly obscure error message. I also find it ironic that you complain about tabs vs spaces, then go on to suggest using python, which also has invisible whitespace as part of its syntax.
- bjourne 13y agoIt's obvious you have exactly 0 experience with waf, yet feel qualified to dismiss it based on objections you have against completely different make alternatives. Make's rule system completely breaks down when you need to create a zip file of all *.c files in a directory tree. But it's a side-point, for complex software, build variants, configuration, installation and distribution are much harder problems to solve than dependency-based compilation. Waf is a replacement for the whole autotools suite, not for GNU make.
- mansr 13y agoYou're right, I have no experience with waf, and I'm not dismissing it. I'm saying much, if not most, criticism of make is unfounded and misplaced. Want a zip file? Use a command like "git archive -o foo.zip HEAD". Why do you insist on having a single tool do all your tasks? A good craftsman has an arsenal of tools and picks the right one for each job.
- bjourne 13y agoTo bad I'm not using git. I still want a zip file of a directory. Really, don't say "use a command like" actually show me exactly how you would accomplish that task, using (gnu) make, in an efficient and cross-platform way without causing unnecessary target rebuilds. You can't? Now you see why make is insufficient.
- ori_b 13y agozipfile.zip: $(wildcard dir/*.c) zip -ur $@ $? Note, $? will only include the prerequisites that are newer than the zipfile, and therefore, will only update the files that have changed. You will not be re-zipping things repeatedly.
- bjourne 13y agoThat's for trying, but 1. doesn't work unless you have zip installed, 2. doesn't recurse the whole directory tree, 3. doesn't rebuild the target if a file is renamed or deleted, 4. uses volatile time stamps instead of content hashes to detect targets needing update. And is GNU make specific. Then what if you want bz2 compression instead of zip?