Make: Theory and Practice
ploxiln.net
ploxiln.net
[blatant advertising] And also I have a new book on GNU make coming out this month: http://www.nostarch.com/gnumake if you really want to get into make deeply.
(Disclaimer; Mr GC is totally not paying me to ask this)
If you are one of the few who bought the old one then it might not be worth buying the new one.
But this book does have exactly 2^8 pages :-)
Like, can't we just get into a little make, and call it square?
Anyone who writes their own, not freely available, manual to a free software program, is dividing the world into two halves: Those readers who can afford this new book, and will pay the author (not the writers of the software, mind you) for a nice manual, and those readers who can’t afford to pay for this new manual, and will have to do with the inferior¹ official manual. Those readers who can afford the new manual will not be incentivised to improve the official manual, since they have the new, better, one. Therefore, this act (of creating new manuals which are not freely available) is reducing the number of readers who can be expected to help improve the official manual to those readers who cannot afford the new manual. These effects, i.e. reduced funding and reduced help to the original software authors, is not, to me, worth it to have a new, even if better, manual.
① Presumably, by their own standards, since they wrote a replacement manual.
> If anyone wants to get into GNU Make deeply, one would think that the obvious thing to do would be to read the official manual for GNU Make.
There is a lot of room for both "user guide" type publications in addition to the official manual. In particular the former may be useful to individuals who have had difficulty learning how to use make from other resources. Are you saying that all of the "Learning Basic Linux" books should be pulled since people can just read the Linux manuals?
> and will pay the author [of the manual] (not the writers of the software, mind you) for a nice manual
You act as if writing a manual is somehow a less valuable act than writing the software, when in fact high-quality documentation is sorely lacking in almost all parts of the free software world.
I doubt you have ever written, edited, and had published a book before, because even for something as "simple" as a guide to a software tool, it is an intense, laborious process that involves lots of research and fact-checking in addition to the actual writing and editing. Its incredibly entitled to suggest that all of this effort should not be compensated at the author's discretion.
> Those readers who can afford the new manual will not be incentivised to improve the official manual, since they have the new, better, one.
They were never incentivized to improve the official manual in the first place.
> reduced funding and reduced help to the original software authors
There was no expectation of funding to the original software authors in the first place, and to imply that they deserve the money for what would be spent on this book, a separate creative work, is disingenuous.
On the contrary, if they had read the official manual, they would have had the incentive to improve it. Just like with software.
> There was no expectation of funding to the original software authors in the first place
Yes there is, if the original software authors are (like in the case of GNU Make) also selling the official manual in book form.
Copyright law is pretty crappy on the whole, but jgrahamc did write the articles and has been giving them away for free. Why is it unreasonable for him to package, edit, update, and release them years after they were written, with the originals still available for free?
Anyway, whatever other good things jgrahamc may have done is immaterial, since I was not only speaking about him, but also about the general case and its consequences. Also, I did not say it was “unreasonable” of anyone to do this. I said that when anyone does something like what jgrahamc did, they take away some unknown amount of human and monetary resources from the authors of the actual software and the official manual, and I don’t think that this drawback is worth it to have a new & improved, but non-freely licenced, manual.
Since the title is "the GNU make book", a consumer could easily mistakes the book as made by the author of GNU make or/and published by the GNU project.
Edit: Missread the article. It was blizzard that got sued for filling the DMCA, not the other way around. A more relevant article is the Harry Potter Lexicon case where a guide to the harry potter works was deemed not protection by fair use. (http://writers.stackexchange.com/questions/8243/can-anybody-...)
Title-wise on jgrahamc's book, that's a different discussion, and completely unrelated to the link you provided.
Your point about trademarks is much more interesting, though; how many people have paid money for this “The GNU Make Book”, thinking that they have somehow supported the GNU Make project? Isn’t this exactly what trademarks are supposed to prevent?
One deficiency I've come across, which seems to be well-known, is the M:N problem -- where one step takes M input files and has N output files. Make rules seem to expect to have only 1 output, and the workarounds like .SECONDARY prevent some features of Make from working correctly.
I've also seen this limitation in many of the fancy new build systems that get posted here on HN.
Is there a build system, a modification to Make, or anything out there that does keep track of builds with multiple outputs? Not an I/O-guzzling MapReduce framework, please.
I did have one percieved speed problem, but this scons calculating file checksums to see if it needed to re-build targets; this is usually a good thing, but if you're working with large files it might be better to use the MD5-timestamp Decider instead.
%.tab.c %.tab.h: %.y
bison -d $<
%.tab.h %.tab.c: %.y
stuff
If you run without parallelism (the default, -j1), it'll work fine, since make will run the rule for one target, and then when it comes to the second one, make will notice that it's already up-to-date (based on file timestamp).
If you run with -j4 or something, it make will likely run the rule twice, simultaneously. That may or may not be a bad problem depending on how the rule writes the output file.
EDIT: man I must have really rushed reading your post... as you say, this does appear to be a heuristic for GNU Make when it's a pattern rule. clearly make is tricky and I end up learning stuff every time I use make...
Anyway, take a look at https://github.com/spotify/luigi, it is basically make-like tool geared toward data pipelines. We are experimenting with it for our data pipeline (which is quite sizeable, ~30TB/day gzipped, thousands of files, a bunch of processing steps) and while it lacks some things, especially in the UI, this approach seems to work quite well.
Allowing steps to partially succeed seems like adding quite a lot of complexity, and I'm not sure where it would be beneficial.
If a multiple-output step fails, I want the outputs to be deleted, and the rest of the dependencies to keep working so I don't have to rebuild everything from scratch. Whatever you're suggesting with dummy targets sounds like it's certainly not going to track the dependencies correctly.
I already know that directories aren't tracked correctly as dependencies.
As for workarounds... this is hacker news, is it not?
You can see the brief list of improvements here:
https://martine.github.io/ninja/manual.html#_comparison_to_m...
(Within Ninja this manifests concretely as needing to represent the build graph as a bipartite graph between files and commands. Though I don't know make's internal representation, I imagine the straightforward implementation is as a graph between files and I can imagine why it'd be difficult to make multiple outputs work in that case.)
However, another way of writing your question is "if you removed the features of make that ninja doesn't have and then optimized the remainder for performance, wouldn't they match?" and that is maybe tautologically true -- that description is roughly what Ninja is, after all.
Because we cared more about performance than other things we maybe were a little crazier about shaving off milliseconds than other systems, so it might be hard to make make fast enough. But (as the Ninja manual suggests) this may only matter for very large (Chrome-sized) projects. You can read a chapter about some of the performance work done on Ninja here: http://www.aosabook.org/en/posa/ninja.html
Not exactly. I'm asking if an implementation of the portable subset of Make people actually use (pointedly excluding GNU Make extensions) could be made nearly as fast as Ninja. That would have the advantage of running existing makefiles, as long as those makefiles weren't written specifically for GNU Make.
When you write "could be made nearly as fast as Ninja", I thought you meant you would change the code of Make or write a new tool. If you don't write a new tool and just use a subset of Make's functionality for your own Makefiles I'd expect those to be faster than your standard Makefiles, sure.
But "existing makefiles" typically use a mixture of GNU make-isms and other things that are not GNU-specific but still slow (e.g. from a skim of the BSD make manual I see lazy variable expansions and control structures). So if you're talking about implementing a subset of Make you're talking about something that's unlikely to be compatible with Makefiles seen in the wild. And then if you're not compatible with Makefiles seen in the wild you've effectively written an incompatible faster subset of Make, which brings us back to what Ninja is. (In case it's not clear, in Chrome's case the same code was used generate Makefiles and Ninja files with some relatively minor output differences -- the tools are that close.)
Perhaps there's some "common" subset of Make that covers some high percentage of build files seen in the wild that could be made faster. That could be valuable to organizations who want faster builds without changing anything. I vaguely recall seeing some commercial software that did this even -- as I recall, their value add was that they had tooling that would figure out how to run your Makefiles in parallel; though Make supports parallel execution, apparently this business found enough customers by just targeting those with underspecified Makefiles that weren't parallel safe and then fixing them!
Anyway, all of this is kinda moot because for 99% of projects Make is plenty fast. I even use Make myself for all my personal projects! In Chrome's case (what we wrote Ninja for) there's so much code that the build files themselves are over ten megabytes of text, so to parse that quickly you're at the level of worrying about avoiding memory allocations in the lexer, which is beyond what most people would care about.
I was partly asking because a fast make-compatible build tool seems easier to switch to, and partly because I wondered how much of Ninja's performance depends on dropping the slow features of make versus adding new capabilities or new syntax.
Okay, now I'm wondering if I could get Make to generate a Ninja file.
Jeez, you know, this is the sort of thing that I would hate to get somewhat deep into using make, only to then discover.
I often see hackers lamenting that a plethora of build tools exist instead of everyone just using make, but I'm not so sure that this state of affairs is less preferable. Maybe it's better if the build tool understands some things about the platform it's building for.
With Electric Make you can mark the rule as producing multiple outputs by adding "#pragma multi" above the declaration. See http://blog.melski.net/2013/01/01/pragma-multi-and-rules-wit....
Disclaimer: I'm the Chief Architect of Electric Make
Then, of course, there's "./configure".
The alternatives tend to be bundled with some giant IDE, or are language-specific. The trend seems to be towards the latter; Go has "go", and rust has "cargo".
Thank you for writing it and posting it here!
In my current very huge (takes hours to build) project at work there is a lot of voodoo around the amount of parallelism you can use. "make -j 4" seems OK, but "make -j 20" fails.
Of course, nobody wants to work on improving the build system.
http://www.cmcrossroads.com/article/pitfalls-and-benefits-gn...
http://highlandsun.com/hyc/#Make
The Chrome/Ninja discussion reminds me of the old mess of X11 IMakefiles. Apparently nothing has really improved since then.
I wrap lots of other build tools in make, so that the way things happen always follows
make setup && make build && make (deploy || install)
No matter the underlying tools. It just makes getting started with one of the many dozens of repos we worth with easier.
This aspect needs to be highlighted to those who have knowledge of imperative/object oriented programming paradigms only.
Otherwise, understanding how those makefiles actually work can become confusing and painful.