Live data from Hacker News

Why Use Make

bost.ocks.org

61–70 of 248 posts

Re: Why Use Make

#62

Earlier quoted context omitted.

"Which one is better depends on the platform you're on" That works against a portable build. That still matters to some of us.

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.

Re: Why Use Make

#64
post #38
post #15

If your project sports auto-generated code, or any sort of build targets that depend on inputs only known after generation -- Make simply cannot handle this. There are ugly workarounds but they don't work well. Make is: * Slow (e.g: when compared with tup[1]) * Very easy to get it wrong (under-specify dependencies), with cryptic bugs (or over-building) as a result. Pretty difficult to get it right (e.g: doing proper…

"or any sort of build targets that depend on inputs only known after generation" Have you tried the gnu make SECONDEXPANSION technique?

Adding a single extra phase is not enough, because you need an arbitrary number of phases to recursively build&scan all dependencies.

Re: Why Use Make

#65
post #55

Everyone points at make and says, "use something better". They point at Rake, they point at Maven. However, Make has one feature that I really need, that I rely on to speed up builds: parallel dependency construction. The last time I checked, neither Maven nor Rake do this properly. Maven runs everything inside a single VM. Who wants to have to worry about multithreading in their unit tests? Rake requires thread supp…

Waf can also do parallel build with proper dependencies, and it's Python-based. Have you looked at it? The documentation is rather clear, but the initial learning curve is probably steeper than make.

Thanks for the pointer, I'll go check it out.

Re: Why Use Make

#66
post #29
post #15

If your project sports auto-generated code, or any sort of build targets that depend on inputs only known after generation -- Make simply cannot handle this. There are ugly workarounds but they don't work well. Make is: * Slow (e.g: when compared with tup[1]) * Very easy to get it wrong (under-specify dependencies), with cryptic bugs (or over-building) as a result. Pretty difficult to get it right (e.g: doing proper…

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 of Haskell), it generates much nicer reports as a result, and it has some other interesting features that tup lacks. Unlike tup, you don't need to specify all the dependencies statically before building anything.

Since tup has some useful features that Shake lacks, I don't think there's a clear winner here. But either one is far preferable to Make in every setting.

Re: Why Use Make

#67
I've started using make for production data generation (not building software) instead of pure Python. Mostly to tie together Python scripts doing the real work.

Pro

-dependency management for free

-well-known paradigm makes it easy for someone other than me to figure out where to look if something went wrong.

-scripts I call out to can be focused

Cons -syntax

-for processes that don't generate an output (think adding data to a file in place) I wind up creating placeholder files ("file.transformA.done").

I actually want my dependency management to be terse and declarative, which is the opposite of what I'm looking for in a programming language, so it feels like a pretty natural divide.

Re: Why Use Make

#68

Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem. There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free. Yes, I know that the essence of…

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/

Re: Why Use Make

#70

From what the example accomplishes, it seems to be that it would have been easier to create a shell script. Is there something I am missing?

I think shell script can work as well as makefile in most cases. The pro of shell script is not having one more tool for running your commands. You have a shell, why do you need make for describing build steps?

For the moment I see a makefile as a shell script that fails when a command fails. But you can use `-e` option with sh, bash, rc shells and expect the same behaviour.

The only thing shell misses (comparing to makefile) is dependencies check, you have to write dependencies mechanism yourself if you need it.

Also I don't like the .PHONY stuff, I just can't get it, it feels alien.

Am I missing anything obvious?

Post reply on HN