6 ms·

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

jonursenbach 13y ago
Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.
- emilis_info 13y ago
  Believe it or not there are people in the world who aren't technical enough to use Grunt or Gulp, because they are much more complicated than Make... Mindblowing, I know.
  - shadowmint 13y ago
    Really no. The makefile syntax is obscure and hard to maintain. We've been there. We don't need to go there again. The stories of 'recursive makefile dependency hell' deserve to stay back in the dark ages of the 90s where they belong. There's a reason lots of people are inventing new systems for doing these sorts of tasks (for example, spawning a local webserver to work with after compiling less and coffee files and parsing the output for errors and displaying them nicely, then watching the filesystem for changes and recompiling on demand). It's not because make is evil, it's because make does a poor job of some of these sorts of tasks. ...if all you're doing is turning .coffee files into .js, it's file, but it's not a solution for complex website builds.
    - emilis_info 13y ago
      Yes, Makefile syntax gets somewhat obscure after the simplicity and power of target definitions and variables (e.g. http://mrbook.org/tutorials/make/ http://mrbook.org/tutorials/make/). Yes, Make does a poorer job at some of the tasks (although spawning a webserver process isn't one of them). But I don't think having to write a plugin for EVERYTHING (http://gratimax.github.io/search-gulp-plugins/ http://gratimax.github.io/search-gulp-plugins/) is a sustainable answer. P.S. I am sorry, I searched for "recursive makefile dependency hell", but I didn't find an explanation of what that is. It would be useful if you could provide some stories. I have been using Make only for two years, so maybe I haven't run into the exact problems yet.
      - phpnode 13y ago
        He's probably referring to this old article - http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf which suggests that recursive make is bad because it can cause a lot of unnecessary processing even if you only changed one or two files. I think this just comes down to how you're using make - for me recursive make works just fine because I tend to run the specific target I need while I'm working (as it's usually in my cwd anyway) and only run the root `make all` on deployment.
- skrebbel 13y ago
  Oh, how I long for the days when condescension was a thing reserved for Lisp programmers.
chubot 13y ago
Why even use Make? I just use shell scripts for automation. The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.
- lowboy 13y ago
  Build utilities like Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. I'm not too familiar with Node's support on various platforms, but I'd wager that it's probably decent. Gruntfiles and Gulpfiles are in javascript too, which lowers the barrier for entry for developers who aren't as versed in linux. Is there a shell script equivalent to npm? Sidenote, that could be really useful as a service.
  - leobelle 13y ago
    > Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. On your own stack and dev environment, why would you care about compatibility of shell scripts? Do you change your stack much?
    - joshuacc 13y ago
      For open-source JavaScript projects, using Grunt or another Node-based tool makes it easier for Windows users to contribute. Node has excellent Windows support, while shell scripts are mostly the domain of *nix.
    - lowboy 13y ago
      Yeah. In the past three years I've gone from Windows, to a CentOS VM, to an Ubuntu VM, now on OS X. Node has worked on all of those platforms. I can't say the same for my .BAT files.
- oinksoft 13y ago
  Make is the easiest way to map all .foo input files to .bar output files and have the outputs only rebuild when the inputs change. This has a ton of applications outside of C and C++, really anything where the build takes time. A shell script cannot adequately express task dependencies, or one that did would become a build tool like make. As it stands, make has a very simple and light syntax for expressing dependencies and has remained useful with little modification for quite some time. Make isn't necessarily the best automation tool, but it's a great build tool.
TheZenPsycho 13y ago
I've been using make myself. The main barrier I keep running into is that it's actually quite challenging to : 1. Use make/bash to work with things like JSON, mustache, images, markdown, less, sass, uglifyjs, etc. etc.. 2. Do so in a way that is portable to even other unixish machines. 3. Why doesn't make provide an easy way to input a BIG LIST of files into a command? The choices (I'm aware of) are to put them all on one line, work out some wildcard (which doesn't work on arbitrary lists of files you need in a particular order), or--- have backslash escaped line endings! yuck! nodejs isn't available in the debian stable packages repo. The available mustache command line tools are pathetically bad at this task (I had to write my own). I can make it work beautifully on my machine, but as soon as it hits my co-workers machine, the build breaks because they haven't installed pandoc, or ripmime, or whatever other utility I had to use to get things done. So, I don't know, maybe I'm doing things wrong. But I haven't got this to work particularly well yet. And uh.. windows. yep.
jonpacker 13y ago
Well, to be fair, make and browserify do completely different jobs. You can't substitute browserify for make, nor vice versa. But to be honest, if you see learning new things as wasting your attention on new fads, I don't think this stuff is for you. I really like trying new things that people have made and seeing what they can do. If that feels like a chore/hardship to you, you absolutely should just keep using make.

jonursenbach 13y ago

Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.

emilis_info 13y ago
Believe it or not there are people in the world who aren't technical enough to use Grunt or Gulp, because they are much more complicated than Make... Mindblowing, I know.
- shadowmint 13y ago
  Really no. The makefile syntax is obscure and hard to maintain. We've been there. We don't need to go there again. The stories of 'recursive makefile dependency hell' deserve to stay back in the dark ages of the 90s where they belong. There's a reason lots of people are inventing new systems for doing these sorts of tasks (for example, spawning a local webserver to work with after compiling less and coffee files and parsing the output for errors and displaying them nicely, then watching the filesystem for changes and recompiling on demand). It's not because make is evil, it's because make does a poor job of some of these sorts of tasks. ...if all you're doing is turning .coffee files into .js, it's file, but it's not a solution for complex website builds.
  - emilis_info 13y ago
    Yes, Makefile syntax gets somewhat obscure after the simplicity and power of target definitions and variables (e.g. http://mrbook.org/tutorials/make/ http://mrbook.org/tutorials/make/). Yes, Make does a poorer job at some of the tasks (although spawning a webserver process isn't one of them). But I don't think having to write a plugin for EVERYTHING (http://gratimax.github.io/search-gulp-plugins/ http://gratimax.github.io/search-gulp-plugins/) is a sustainable answer. P.S. I am sorry, I searched for "recursive makefile dependency hell", but I didn't find an explanation of what that is. It would be useful if you could provide some stories. I have been using Make only for two years, so maybe I haven't run into the exact problems yet.
    - phpnode 13y ago
      He's probably referring to this old article - http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf which suggests that recursive make is bad because it can cause a lot of unnecessary processing even if you only changed one or two files. I think this just comes down to how you're using make - for me recursive make works just fine because I tend to run the specific target I need while I'm working (as it's usually in my cwd anyway) and only run the root `make all` on deployment.
skrebbel 13y ago
Oh, how I long for the days when condescension was a thing reserved for Lisp programmers.

chubot 13y ago

Why even use Make? I just use shell scripts for automation. The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.

lowboy 13y ago
Build utilities like Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. I'm not too familiar with Node's support on various platforms, but I'd wager that it's probably decent. Gruntfiles and Gulpfiles are in javascript too, which lowers the barrier for entry for developers who aren't as versed in linux. Is there a shell script equivalent to npm? Sidenote, that could be really useful as a service.
- leobelle 13y ago
  > Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. On your own stack and dev environment, why would you care about compatibility of shell scripts? Do you change your stack much?
  - joshuacc 13y ago
    For open-source JavaScript projects, using Grunt or another Node-based tool makes it easier for Windows users to contribute. Node has excellent Windows support, while shell scripts are mostly the domain of *nix.
  - lowboy 13y ago
    Yeah. In the past three years I've gone from Windows, to a CentOS VM, to an Ubuntu VM, now on OS X. Node has worked on all of those platforms. I can't say the same for my .BAT files.
oinksoft 13y ago
Make is the easiest way to map all .foo input files to .bar output files and have the outputs only rebuild when the inputs change. This has a ton of applications outside of C and C++, really anything where the build takes time. A shell script cannot adequately express task dependencies, or one that did would become a build tool like make. As it stands, make has a very simple and light syntax for expressing dependencies and has remained useful with little modification for quite some time. Make isn't necessarily the best automation tool, but it's a great build tool.

TheZenPsycho 13y ago

I've been using make myself. The main barrier I keep running into is that it's actually quite challenging to : 1. Use make/bash to work with things like JSON, mustache, images, markdown, less, sass, uglifyjs, etc. etc.. 2. Do so in a way that is portable to even other unixish machines. 3. Why doesn't make provide an easy way to input a BIG LIST of files into a command? The choices (I'm aware of) are to put them all on one line, work out some wildcard (which doesn't work on arbitrary lists of files you need in a particular order), or--- have backslash escaped line endings! yuck! nodejs isn't available in the debian stable packages repo. The available mustache command line tools are pathetically bad at this task (I had to write my own). I can make it work beautifully on my machine, but as soon as it hits my co-workers machine, the build breaks because they haven't installed pandoc, or ripmime, or whatever other utility I had to use to get things done. So, I don't know, maybe I'm doing things wrong. But I haven't got this to work particularly well yet. And uh.. windows. yep.

jonpacker 13y ago

Well, to be fair, make and browserify do completely different jobs. You can't substitute browserify for make, nor vice versa. But to be honest, if you see learning new things as wasting your attention on new fads, I don't think this stuff is for you. I really like trying new things that people have made and seeing what they can do. If that feels like a chore/hardship to you, you absolutely should just keep using make.