Live data from Hacker News

Why Use Make

bost.ocks.org

81–90 of 248 posts

Re: Why Use Make

#81
post #66
post #29

Earlier quoted context omitted.

Have you used tup? I have encountered on the web, and it looks very well done. But I never hear about anyone using it. Is it just under-publicized? People sometimes talk about waf as an alternative. I took a look at waf awhile aback and I felt disappointed, I forget why. I think node.js switched off waf for some reason I don't recall; either that or they didn't like it.

I used tup, and it has its shortcomings. I would never prefer Make to tup though, even with its shortcomings. I am now working with Shake, and it seems to be the nicest I've used yet. It is not as robust as tup at verifying there are no under-specified dependencies, nor at detecting what needs to be rebuilt when a build script changes. But it is much more flexible (you get to write a build script with the full power…

What are the shortcomings of tup? That you have to specify dependencies statically?

Re: Why Use Make

#82
post #56

Earlier quoted context omitted.

"But I think the metrics you've chosen are irrelevant." Nothing is more frustrating than discovering that you need to install a new component or build system just to build a specific component. It gets worse when dealing with multiple external components in different build systems. "It's also very hard to learn and very difficult to maintain" I agree insofar as most people go into make without trying to learn it prop…

Indeed, mseebach's answer is really saying that those metrics are irrelevant to him .

No, what I'm really saying is that if you get to cherry-pick the metrics, you can win any debate.

Of course there are tradeoffs in anything, and if the expressiveness of your build script is the deal-breaker for your project, by all means use make. On the whole, I will still argue that more modern alternatives provide a better total experience. Also, note that the OP is directed at beginners.

Re: Why Use Make

#83

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.

Re: Why Use Make

#84
post #81
post #66

Earlier quoted context omitted.

I used tup, and it has its shortcomings. I would never prefer Make to tup though, even with its shortcomings. I am now working with Shake, and it seems to be the nicest I've used yet. It is not as robust as tup at verifying there are no under-specified dependencies, nor at detecting what needs to be rebuilt when a build script changes. But it is much more flexible (you get to write a build script with the full power…

What are the shortcomings of tup? That you have to specify dependencies statically?

Yeah, though it is not that horrible since tup allows you to over-specify dependencies with very minor ill-effects (less parallelism, but no over-building).

My list of short-comings besides that are:

* No "run" command on Windows, means if you want portable tup you're stuck with its primitive scripting language (or reverting to Make-style hacks like ugly multi-phase build that generates the Tupfiles)

* Has an arbitrary restriction on rule line size. So if you do use "run", and have large targets that have tons of dependencies, you may hit a dreaded: "Line too long" error.

* Has some trouble because of its fuse-based system to capture dependencies. Commands are exposed to weird paths in ~/.tup/mnt/ and such. The abstraction sometimes leaks.

All in all, these short-comings are very minor compared to Make's huge ones :)

Re: Why Use Make

#85
I think what you were looking for here is actually a shell script, rather than a Makefile. A shell script is much more suitable for general purpose programming. Or better yet, use Python ;-) And, let's admit it, for small projects dependency analysis is overrated (although it can be implemented easily enough in a real programming language).

Re: Why Use Make

#86

Earlier quoted context omitted.

By 'platform' I meant programming language and execution environment (JVM/Ruby/Python), not OS.

I'm fond of not having the number of build systems I'm responsible for maintaining grow in step with the number of programming languages I use in a project.

All build systems I've come across are quite happy to build code in other languages - just like make. The reason I'd recommend the dominant system in each ecosystem is, well, that: It's dominant, thus likely to be better supported for the issue you're likely to face.

Re: Why Use Make

#87
post #83

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 ma…

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.

Re: Why Use Make

#88
post #68

Earlier quoted context omitted.

Lots of "Don't do this" without suggesting alternatives doesn't do anyone much good. If you're on a *nix system, building C/C++ programs (or automating one-off builds like the example), what would you recommend in make's place?

I'd suggest tup[1] and Shake[2]. [1]: http://gittup.org/tup/ [2]: http://community.haskell.org/~ndm/shake/

Thanks for the links! I will definitely use tup for some next project. I try from time to time different make-like systems but I always come back to GNU Make. I also don't fear the GNU Make Reference. But tup looks, again, quite promising. It even has those little context sensitive one-special-char one-letter variables :) But they do something better by design, I see http://gittup.org/tup/make_vs_tup.html

Re: Why Use Make

#89
"Makefiles are machine-readable documentation ... "

Yes it is machine readable but how about us humans? Makefiles are ugly and when working on someone else's project it is very hard to reverse engineer the build system. Build systems are themselves software projects and we need better tools to develop and maintain them.

SCons was a promising project at one point, it improved things by capturing the build system in Python classes. I thought things would be more maintainable and readable. However for me it wasn't a well design, it obscures build system development with mixed declarative and iterative programming.

Makefiles are the defacto standard today, but they're no where near beautiful, or maintainable, or readable.

There are also variations of it such as gmake, imake, and so on, who only add their own quirks without solving the real problems.

Re: Why Use Make

#90
I once used gmake to implement a multi-stage Mechanical Turk workflow.

It was awful. The syntax sucks. But it worked consistently, and the core logic was only 110 lines of Makefile. It described the files and the data flow between them. Even now, I can read it and understand it with not too much effort.

Make is a very simple functional language. It's restartable. If you type 'make -j 2' it becomes parallelizable. For almost anything for which you might write a shell script, you have to ask yourself: Why not make instead?

I would like a cleaner, kinder make, but I also want it to retain make's essential make-iness. Nothing else seems to do that.

I do feel bad for anyone downstream of my makefiles, though.

Post reply on HN