Hacker News Reader

Comment by jgrahamc | Hacker News Reader

If you use GNU Make it's worth using my GNU Make Standard Library: http://gmsl.sourceforge.net/

And also reading everything I wrote as Mr. Make: http://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-arti...

Or buy my book: http://www.lulu.com/shop/john-graham-cumming/gnu-make-unleas...

I'll have to respectfully disagree. IMHO, the utility of DSLs like Make is high when used very sparingly, for simple flows like the one the linked article describes. The more complex your Makefile, the less you should be using Make. If you need to write complete programs in Make, just stop bending over backwards and pick a real programming language.

FWIW most non-trivial projects nowadays that use Make don't write makefiles directly but use make generators like CMake and Gyp.

Make is the assembly/C language of build system. Lots of other systems just generate makefile compatible files (qmake, cmake, premake, others), but often these fall into overly complex traps trying to explain everything both with simple unique words, and then clashing into these.

Make is very optimal at the stage it is, everything above or below it it's just not that optimal.

As the assembly language of build systems, I agree that Make works well. But there, IMHO, its utility ends.

I would say if fares rather poorly when you compare it something like ninja (http://martine.github.com/ninja/) which is made to be generated by tools Gyp or CMake. I have used the CMake+ninja combination on large projects and it lives up the hype.

> Make is very optimal at the stage it is, everything above or below it it's just not that optimal.

Right: GNU Make is at a local optimum for describing how to generate products based on rules and a dependency graph. I'd also wager it's close to a global optimum.

GNU Make is certainly closer to that global optimum than Boost's jam or the countless homegrown XML-based things I've seen over the years --- make is powerful, but despite that power, simple things look simple and are simple to write. In other systems, either simple things are hard to write or the system itself is so simple than it's not powerful enough to describe what I want done.

If Make is a local optimum and close to a global optimum, it by definition is the global optimum.

Cute, but that depends how close...

Say you have a city with two skyscrapers on opposite sides of town, one 49 stories high and the other 51 stories high. When you're at the top of the 49-story building, you're at a local maximum of height and close to the global maximum, but you're not exactly a short gradient-ascent jaunt away from the global maximum.

Sure, but how much work are you going to put in to go up two floors? Local optimum + close to a global optimum means there's not much cost benefit in changing.

Exactly. That's what Make is still used.

Not really, depends on definition of "close", i.e. how you measure distance. If closeness means distance in search space, then you're right, but it also could mean local vs global are close in value being optimized, but they are located far from each other in search space.

Which "homegrown XML things"?

Well... If by XML-based things you are thinking of Maven, they're not really at the same level. Maven is much more higher-level, and is fully declarative, which is both a blessing and a curse. I would not describe it as a general-purpose build system, it's really made for the Java ecosystem, but in this context, it works well for a majority of projects, because they can follow the rails. And it does handle out of the box automated retrieval of dependencies, which is way outside the scope of make.

It has its hear in the right place, though. High-level build systems should strive to be as declarative as possible. It's the rest of the design which is problematic :)

I think he was more talking about tools like Apache Ant.

I haven't really used Make in any big projects (read: 100s of files and dependencies), but that's mainly because I have a habit of breaking components into smaller projects and thus keeping things, including my Makefiles, very simple. For project structures like that, I think your tools and book are overkill, so I'll recommend this reference from Oreilly's UNIX in a nutshell. I found that this is by far the most easily digestible reference for GNU Make I can find that's free. It's fairly to the point and concise as far as reference go, you can read the whole thing and have a fairly good understanding in under an hour. It's a reference that I go to 90% of the time, the other 10% come from Google and trial and error.

http://oreilly.com/linux/excerpts/9780596100292/gnu-make-uti...

Why does the pdf version cost more than the paperback?

I'd really like an answer to this. It greatly annoys me when I see this type of thing and it always pisses me off so much that I usually forego getting the book. Perhaps I'm over reacting, but to me, it indicates a lack of respect for the audience. Are we so stupid 1) we won't notice, and 2) we can't figure out mailing a physical thing has to have more overhead than the digital copy?

That is exactly how I feel. I was literally about to purchase the book but that changed my mind.

Good question.

In the Lulu interface I have the prices set at $15 for the print book and $9.99 for the PDF/ePub versions. It appears that something weird happened with EUR and USD. Originally I had these priced in EUR and switched currencies.

Apologies for that, I've reset everything and it looks right now.

Awesome! Just bought it.

gmsl is a wonderful, well considered library. I had to buy the book after finding it.

Thanks!

Reply on news.ycombinator.com