Hacker News new | ask | show | jobs
by jdp 4217 days ago
The "horrific syntax and semantics" claim seems pretty drive-by, the variables and some function names might be arcane, but newer releases have nicer aliases for those who care for them. I don't know what is so horrific about the semantics though, they are pretty straightforward. A Makefile is a set of rules, each rule being a target file, its dependencies, and the recipe to turn the dependencies into the target. Make can figure out which steps need to actually run based on the states of the targets and dependencies (prereqs in Make terms). It's a really powerful way to describe the relationships and transformation steps for files, and you get partial builds for free! Not that make is without problems (the initiative behind DJB's redo addresses them at length) but unsubstantiated FUD isn't necessary.
1 comments

> unsubstantiated FUD isn't necessary

Sure.

...but to be fair, regardless of the make syntax, you've also got to look at the history of make, and what it's designed to achieve.

Make is for executing shell commands on file patterns with dependency rules.

It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes). It's not designed to be a scripting language (although it can be, since it's technically turing complete).

Now, when you look at other things which have come along to replace make as a build tool: cmake, grunt, gulp, ant, rake, maven, scons, premake, etc.

I think it's probably a little bit superscillious to suggest that all the people building these tools were just too retarded to realize how good make was.

More likely, they had specific needs that make didn't address.

Rust, for example, just recently had a reasonable make based solution, but they decided to depreciate it in favour of cargo, because it was simply too difficult to support in an appropriate cross platform manner.

Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.

Is it the right tool for fetching the dependencies of and invoking a large set of ruby/javascript/python scripts and plugins to build the assets for a website, running a local development server and watching file changes and pushing livereload changes to the browser as the files change?

No. Make is absolutely rubbish at doing those things.

...not because make is rubbish, but because it's not for doing those sorts of things.

> Make is for executing shell commands on file patterns with dependency rules.

Yep absolutely. Make is a system for generating files from other files, it is that simple. Compiling templates and code, generating source maps, concatenating, minifying -- many of these tasks all fall under that umbrella.

> It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes).

You're right, I wouldn't advocate that either. Procfiles and tools like foreman (and it's various reimplementations, like honcho) are for managing those processes: development servers, file watchers, etc. That's actually my own personal approach, I go for the Makefile/Procfile combo and run `foreman start` to boot up the a server and any other processes that project might need. Works pretty well for me.

> Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.

That's a pretty narrow view, like I said earlier, it's good for any application where you're generating files from other files. Building an ebook, managing unwieldy SSH configurations (smdh at lack of include directive in SSH config), etc.

So yeah I agree make is no good at being an all-in-one everything-and-the-kitchen-sink suite. And that's great. It has one job and does it well enough, and is even better complemented by other tools. Some people like the suite approach better, but I wouldn't disparage make for something it wasn't intended to do to begin with.

Great explanation of limitations of make. Regarding when someone says make i availible everywhere and forgets Windows I think we can start saying Javascript/Node is everywhere (not preinstalled but easily availible). It is probably more true.