5 ms·

The problem with make is not that it's bad, it's that's it's only really good at doing two things: 1) mapping a source pattern to an output pattern 2) managin

The problem with make is not that it's bad, it's that's it's only really good at doing two things: 1) mapping a source pattern to an output pattern 2) managing dependencies between rules To be fair it's good at those, and often the sorts of things you can do with a rule are quite complex (being basically shell scripts). However, the problem is that 1) it's an obscure DSL and 2) that it is really rubbish at doing more complicated things. For example, grunt-contrib-clean lets you: delete any files that match a regex, not leave alone any files that match a different regex. Grunt also has a built in templating language that can be used to expand configuration files from submodule into local build scripts without copying the entire gruntfile. grunt-open launches a browser to a dev url cross platform. The list goes on and on and on. Make is terribly terribly bad at complex tasks like this, that's the problem. You can write a custom shell-script / ruby-script / python-script for these tasks, but why would you? Someone else already has. Dont repeat all the things every time with your own code. If all you need to do is map .c to .o, or .scss to .css and .coffee to .js, use make, totally. It's good at that. Otherwise, stay away.

rwmj 13y ago
I'll offer my own input here, goaljobs[1]. (By the way I don't recommend people to use goaljobs unless you're prepared for a lot of assembling and are interested in understanding what it does -- it's not easy to use at all). You can break down complex tasks like "Has my software been delivered through the app store" down to goals that have to be fulfilled by carrying out (recursively) many layers of rules, like "did it pass human evaluation?". It's a generalization of make / build systems. [1] http://people.redhat.com/~rjones/goaljobs/ http://people.redhat.com/~rjones/goaljobs/
gkya 13y ago
There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've specified can be done with standard UNIX utilities, whereas you depend on third-party libraries with grunt. Also, I do not think that any of those tasks are complex. I'd rather rewrite a 4-LOC shell script in my new project, instead of depending on a build tool that depends on a non-standard, infant runtime itself, and also depends on third party libraries for deleting files.
- auvrw 13y ago
  i was going to say something in response to the article about dependencies from a positive standpoint for grunt, but i think it makes sense to put it here. rather than having a unix development environment for the browser platform, thanks to lighttable, grunt, and others, it's possible to use node/web-browsers as a development environment as well. i guess node isn't as venerable as unix or even the jvm for that matter, but is "infant" really a fair characterization? i've heard that node can actually do some types of string processing faster than the jvm. i totally agree on starting with shell scripts, though. i tend to put short scripts all throughout repos, even if they just run a single command with a few arguments. sometimes they grow into longer scripts, and sometimes they get changed to run different programs (e.g. grunt<->make), but having a few consistent names for tasks like build, run, test, and deploy (.sh) across projects and languages goes a long way to cut back on cognitive load.
  - gkya 13y ago
    > ... but is "infant" really a fair characterization? The point I wanted to make was that one needs to install node to run grunt; I don't believe there's any OS that distributes node in the base distribution, whereas make and sh is a part of the POSIX standard, and perl/python is available by default on most OS's. Also, node is indeed infant and young, don't consider that a bad characterisation, I do enjoy playing with node. My plea is that one should not need to install some software to run the build scripts in a project they download.
- shadowmint 13y ago
  grunt uses a JSON file Actually grunt uses a javascript file you can drop node code into (not a stupid DSL, an actual programming language no less). I'd rather rewrite a 4-LOC shell script in my new project... Anyway, if you want to throw away your precious developer hours writing yourself a new makefile build system for every project and throw away the nice principles of code reuse, you can. ...just maybe don't tell who ever is paying you that you're doing it that way. (or wait, you can reuse code with make can't you? It's called autoconf or something like that...)

rwmj 13y ago

I'll offer my own input here, goaljobs[1]. (By the way I don't recommend people to use goaljobs unless you're prepared for a lot of assembling and are interested in understanding what it does -- it's not easy to use at all). You can break down complex tasks like "Has my software been delivered through the app store" down to goals that have to be fulfilled by carrying out (recursively) many layers of rules, like "did it pass human evaluation?". It's a generalization of make / build systems. [1] http://people.redhat.com/~rjones/goaljobs/ http://people.redhat.com/~rjones/goaljobs/

gkya 13y ago

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've specified can be done with standard UNIX utilities, whereas you depend on third-party libraries with grunt. Also, I do not think that any of those tasks are complex. I'd rather rewrite a 4-LOC shell script in my new project, instead of depending on a build tool that depends on a non-standard, infant runtime itself, and also depends on third party libraries for deleting files.

auvrw 13y ago
i was going to say something in response to the article about dependencies from a positive standpoint for grunt, but i think it makes sense to put it here. rather than having a unix development environment for the browser platform, thanks to lighttable, grunt, and others, it's possible to use node/web-browsers as a development environment as well. i guess node isn't as venerable as unix or even the jvm for that matter, but is "infant" really a fair characterization? i've heard that node can actually do some types of string processing faster than the jvm. i totally agree on starting with shell scripts, though. i tend to put short scripts all throughout repos, even if they just run a single command with a few arguments. sometimes they grow into longer scripts, and sometimes they get changed to run different programs (e.g. grunt<->make), but having a few consistent names for tasks like build, run, test, and deploy (.sh) across projects and languages goes a long way to cut back on cognitive load.
- gkya 13y ago
  > ... but is "infant" really a fair characterization? The point I wanted to make was that one needs to install node to run grunt; I don't believe there's any OS that distributes node in the base distribution, whereas make and sh is a part of the POSIX standard, and perl/python is available by default on most OS's. Also, node is indeed infant and young, don't consider that a bad characterisation, I do enjoy playing with node. My plea is that one should not need to install some software to run the build scripts in a project they download.
shadowmint 13y ago
grunt uses a JSON file Actually grunt uses a javascript file you can drop node code into (not a stupid DSL, an actual programming language no less). I'd rather rewrite a 4-LOC shell script in my new project... Anyway, if you want to throw away your precious developer hours writing yourself a new makefile build system for every project and throw away the nice principles of code reuse, you can. ...just maybe don't tell who ever is paying you that you're doing it that way. (or wait, you can reuse code with make can't you? It's called autoconf or something like that...)