[chubot]

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.

[noir_lord]

Your post just punched me in the gut.

I've spent the last couple of weeks playing the "front end build tool dance" (primarily a back end dev) to find a system I like and it simply never occurred to me I could write my own as a quick bash script or python if I think it'll grow.

That's an embarrassing oversight.

[chubot]

Good :) Shell scripts will be around for a lot longer than any of those tools.

Shell is also significantly easier and faster, if you just want to say run jslint, then minify, etc.

I program in lots of languages, so shell is the first tool I reach for. Learning the language is enough; I don't have time for all these quirky build and deploy tools.

[noir_lord]

The embarrassing part is I automate everything with the shell and still never thought of it :).

[lowboy]

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]

> 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]

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]

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.

[emilis_info]

You can pack several shell scripts into one Makefile as .PHONY targets. You can share configuration values, subtasks between the tasks. It is somewhat easier to supply options to tasks e.g.:

    make deploy SERVER=example.com

Shell syntax is horrible itself. Make doesn't add too much on top of that.

[oinksoft]

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.

[ufo]

Not writing task dependencies is kind of a feature though, in a KISS way. One of the reasons I have been tending towards using stupid shell scripts is that its much easier to guarantee that everything is built correctly if you rebuild from scratch everytime. With make I often find myself dealing with bugs in the makefile due to forgetting to specify some dependency or things like that.

[jhh]

Saying that Make is a horribly implemented Shell dialect clearly seems like a misrepresentation of Make to me.

Make is a non-procedural way to describe the dependencies of your build process. You describe what you want as a result rather than the steps that the interpreter should follow.

It's possible to like or dislike this approach but it's clearly qualitatively different from Shell scripting.

[chubot]

I understand that distinction, but my point is that for automation like running jslint or minify, the dependencies aren't that necessary. Those commands don't take very long, and often don't have long dependency chains.

Make basically adds a very small "declarative" dependency layer, and then reimplements the shell poorly:

   - variables (from the environment)
   - command tokenization
   - escaping rules
   - functions
   - if statements
   - include
   - globbing (in the target line)
   - various magic $ variables
   - process substitution
   - eval
   ... etc.

That is, it's a full fledged programming language with different syntax than shell, but mostly the same features. I guess what might do in some cases is have a very simple "actions.sh" shell script, and then a Makefile which ONLY has simple command lines calling into actions.sh. Any functions would be in bash rather than make.

This is actually nice because there is an "upgrade path". For most simple things, you can just stick with shell. But when you need the power of make, you can upgrade without rewriting anything -- just adding a short/readable makefile.

[mercurial]

Autocompletion of make targets in the shell.

[chubot]

I wrote my own completion for that :) Here is the pattern I use:

   run.sh

   build() {
     ...
   }

   test() {
     ...
   }

   deploy() {
     ...
   }

   # This lets you do ./run.sh build foo bar at the command 
   # line.  The autocomplete scans for functions in .sh files
   # and fills them in as the first arg.

   "$@"