6 ms·

Why don't people just use make?

by jdub 12y ago

endgame 12y ago
People are scared of significant whitespace or old software or something.
- bhaak 12y ago
  I'm not sure how serious your comment is but this was one of the reasons for the invention of Apache Ant. For years, the front page of Ant had a rant towards Makefiles on it, including this highly unprofessional quote: '"Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times.' https://web.archive.org/web/20100203102803/http://ant.apache.org/ https://web.archive.org/web/20100203102803/http://ant.apache... They only removed it in 2010 with the release of 1.8.0.
tree_of_item 12y ago
Make has really horrific syntax and semantics, and doesn't integrate as nicely if you're dedicated to JavaScript. I mean, the Unix philosophy is about small programs that work together, not "only use old Unix tools". I'm reminded of https://news.ycombinator.com/item?id=5106767 https://news.ycombinator.com/item?id=5106767
- jdp 12y 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.
  - shadowmint 12y ago
    > 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.
    - jbergens 12y ago
      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.
    - jdp 12y ago
      > 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.
stephenr 12y ago
Because it's not the new cool thing obviously.
droidist2 12y ago
Jake is pretty nice. http://jakejs.com/ http://jakejs.com/
mietek 12y ago
FWIW, I do use make. I could not deal with gulp’s issues[1], so I wrote a little thing of my own, just to quickly whip up websites for my projects[2]. [1]: https://github.com/gulpjs/gulp/issues/651 https://github.com/gulpjs/gulp/issues/651 [2]: https://cannot.mietek.io https://cannot.mietek.io
skybrian 12y ago
One reason might be so that contributors on Windows don't have to install cygwin and nobody has to worry about the differences between various flavors of make. If you want things to work cross-platform, it's easier to start with a portable language.
demarq 12y ago
It's hell for those of us outside of the Unix ecosystem. I have MSYS on my Windows machine and make works only half of the time. Also the learning curve is just not as easy, nor the files as readable. With Gulp and Grunt you are exploiting the fact that almost everyone can write a couple of lines of JavaScript. The only thing you are adding is an api composed of three to four functions. If you look at make on the other hand, you'll need to learn quite a lot. http://www.gnu.org/software/make/manual/make.html http://www.gnu.org/software/make/manual/make.html
- Guillaume86 12y ago
  Yes I'm on windows and already had the case of a npm package I would have liked to contribute but the build process was using make, couldn't make it work... It's a bit disapointing when you have a very good multiplatform ecosystem to see stuff like that, sometimes it's people "forgetting" there's also windows (and I can get that), but some other times it's just a big "fuck you windows user".
  - jcbrand 12y ago
    The general sentiment has been "fuck you linux user" for so long now, it's funny to see how things have changed in the last 15 years or so.
    - Guillaume86 12y ago
      I'm not sure what precisly you're referring to (proprietary software/drivers?), I love linux, used it almost exclusively for 5 years before my current .NET job. I'm talking here about pure javascript npm packages, something you can legitimatly expect to be able to build on windows and yet some people make childish judgements on windows users and choose tools which exclude a part of the community (not always the case or the reason but it happens). On a similar subject, I stopped counting the times I've seen someone get told to get a Mac when discussing a problem on cross platform tools.
chrisan 12y ago
Is there a way to do a filewatch -> sass -> livereload with make? That was the primary reason for me using grunt.
- jdp 12y ago
  I wouldn't use make for file watching and live reloading. I would express the Sass and CSS dependencies in a Makefile, and then describe the dev server, file watching[1], and live reloading[2] processes in a Procfile, using something like foreman[0]. [0]: http://ddollar.github.io/foreman/ http://ddollar.github.io/foreman/ [1]: http://entrproject.org/ http://entrproject.org/ [2]: https://www.npmjs.org/package/livereload https://www.npmjs.org/package/livereload
pjmlp 12y ago
Because it isn't portable, not even across UNIX/POSIX systems. Each make has it own set of extensions outside of what POSIX requires. Additionally, for almost every task you need to call out to external tools that also have their own set of compatibility issues across UNIX/POSIX systems. Ideally everyone writing a Make script would need to read the POSIX standard and only use common features, but since that isn't the case, scripts break across systems. This is what lead to autotools/autoconf creation.
- rbanffy 12y ago
  > Because it isn't portable, not even across UNIX/POSIX systems. How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?
  - pjmlp 12y ago
    You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-Kernel/POSIX, LynxOS... There are lots of POSIX systems out there.
    - rbanffy 12y ago
      I know people who develop (and use make) on BSD and OS X (I do), but, seriously, is any OS on our lists (OS X, (Open)Solaris-derivations and *BSD excepted) likely to be the target for the kind of software Grunt is used to develop?
      - pjmlp 12y ago
        Most likely not, my point was just to pass the information specially to those stuck in GNU/Linux, that it isn't as portable as many think it is.
        rbanffy 12y ago
        GNU Make is probably available on all those platforms.

Why don't people just use make?

by jdub 12y ago

Why don't people just use make?

endgame 12y ago

People are scared of significant whitespace or old software or something.

bhaak 12y ago
I'm not sure how serious your comment is but this was one of the reasons for the invention of Apache Ant. For years, the front page of Ant had a rant towards Makefiles on it, including this highly unprofessional quote: '"Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times.' https://web.archive.org/web/20100203102803/http://ant.apache.org/ https://web.archive.org/web/20100203102803/http://ant.apache... They only removed it in 2010 with the release of 1.8.0.

tree_of_item 12y ago

Make has really horrific syntax and semantics, and doesn't integrate as nicely if you're dedicated to JavaScript. I mean, the Unix philosophy is about small programs that work together, not "only use old Unix tools". I'm reminded of https://news.ycombinator.com/item?id=5106767 https://news.ycombinator.com/item?id=5106767

jdp 12y 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.
- shadowmint 12y ago
  > 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.
  - jbergens 12y ago
    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.
  - jdp 12y ago
    > 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.

stephenr 12y ago

Because it's not the new cool thing obviously.

droidist2 12y ago

Jake is pretty nice. http://jakejs.com/ http://jakejs.com/

mietek 12y ago

FWIW, I do use make. I could not deal with gulp’s issues[1], so I wrote a little thing of my own, just to quickly whip up websites for my projects[2]. [1]: https://github.com/gulpjs/gulp/issues/651 https://github.com/gulpjs/gulp/issues/651 [2]: https://cannot.mietek.io https://cannot.mietek.io

skybrian 12y ago

One reason might be so that contributors on Windows don't have to install cygwin and nobody has to worry about the differences between various flavors of make. If you want things to work cross-platform, it's easier to start with a portable language.

demarq 12y ago

It's hell for those of us outside of the Unix ecosystem. I have MSYS on my Windows machine and make works only half of the time. Also the learning curve is just not as easy, nor the files as readable. With Gulp and Grunt you are exploiting the fact that almost everyone can write a couple of lines of JavaScript. The only thing you are adding is an api composed of three to four functions. If you look at make on the other hand, you'll need to learn quite a lot. http://www.gnu.org/software/make/manual/make.html http://www.gnu.org/software/make/manual/make.html

Guillaume86 12y ago
Yes I'm on windows and already had the case of a npm package I would have liked to contribute but the build process was using make, couldn't make it work... It's a bit disapointing when you have a very good multiplatform ecosystem to see stuff like that, sometimes it's people "forgetting" there's also windows (and I can get that), but some other times it's just a big "fuck you windows user".
- jcbrand 12y ago
  The general sentiment has been "fuck you linux user" for so long now, it's funny to see how things have changed in the last 15 years or so.
  - Guillaume86 12y ago
    I'm not sure what precisly you're referring to (proprietary software/drivers?), I love linux, used it almost exclusively for 5 years before my current .NET job. I'm talking here about pure javascript npm packages, something you can legitimatly expect to be able to build on windows and yet some people make childish judgements on windows users and choose tools which exclude a part of the community (not always the case or the reason but it happens). On a similar subject, I stopped counting the times I've seen someone get told to get a Mac when discussing a problem on cross platform tools.

chrisan 12y ago

Is there a way to do a filewatch -> sass -> livereload with make? That was the primary reason for me using grunt.

jdp 12y ago
I wouldn't use make for file watching and live reloading. I would express the Sass and CSS dependencies in a Makefile, and then describe the dev server, file watching[1], and live reloading[2] processes in a Procfile, using something like foreman[0]. [0]: http://ddollar.github.io/foreman/ http://ddollar.github.io/foreman/ [1]: http://entrproject.org/ http://entrproject.org/ [2]: https://www.npmjs.org/package/livereload https://www.npmjs.org/package/livereload

pjmlp 12y ago

Because it isn't portable, not even across UNIX/POSIX systems. Each make has it own set of extensions outside of what POSIX requires. Additionally, for almost every task you need to call out to external tools that also have their own set of compatibility issues across UNIX/POSIX systems. Ideally everyone writing a Make script would need to read the POSIX standard and only use common features, but since that isn't the case, scripts break across systems. This is what lead to autotools/autoconf creation.

rbanffy 12y ago
> Because it isn't portable, not even across UNIX/POSIX systems. How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?
- pjmlp 12y ago
  You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-Kernel/POSIX, LynxOS... There are lots of POSIX systems out there.
  - rbanffy 12y ago
    I know people who develop (and use make) on BSD and OS X (I do), but, seriously, is any OS on our lists (OS X, (Open)Solaris-derivations and *BSD excepted) likely to be the target for the kind of software Grunt is used to develop?
    - pjmlp 12y ago
      Most likely not, my point was just to pass the information specially to those stuck in GNU/Linux, that it isn't as portable as many think it is.
      - rbanffy 12y ago
        GNU Make is probably available on all those platforms.