Hacker News Reader

Comment by gjvc | Hacker News Reader

I'm pleased to see this being espoused. One thing I always tell junior people is ""don't be tempted to think of make(1) as out-of-date [1], and to view packages available via npm etc as better replacements, as many tasks fit the model of make(1), if not the title "a program for directing recompilation" "" I am often viewed with suspicion until I show them a (much more compact) replacement for their custom python/js program expressed as a makefile without any of the process management requiring debugging. :-)

An alternative approach for the "batches of files to process" situation is to generate the commands and feed them to GNU parallel for execution.

[1] no pun intended

View on HN

Speaking of debugging, I found this handy:

  print-%: ; @echo '$(subst ','\'',$*=$($*))'
  include Makefile

Save somewhere, eg as ~/Makefile.debug, then when you want to know the evaluated value of some variable or task in some Makefile, you prefix it with print- — for example, LOCALES:

  make -f ~/Makefile.debug print-LOCALES

It'll print the evaluated LOCALES of the Makefile in the directory you run this in.

This is amazing. Thank you for the tip!

Very useful, will give it a shot. Thank you. :-)

Agreed if you only have to support linux/unix, but the one good thing about the Node ecosystem is that they tend to work on windows too.

Make has worked on Windows longer than Node.js has existed.

Make works fine, it's the commands you call from make that don't tend to as compatible. For example, try running rm -rf on windows. It might work if you have GNU tools installed, but it certainly won't work out of the box. On the other hand, the node.js `rimraf` package will do the same thing with no cross-platform compatibility issues.

When using package.json, does npm intercept a script containing "rm -rf" and translate it to something different?

No, that's why there's a bunch of packages such as rimraf[0] that implements that sort of functionality in a cross-platform way that most people use in their scripts

[0]: https://www.npmjs.com/package/rimraf

No, but it does put binaries from any installed node packages in your PATH (locally when running scripts).

The history of Make on Windows would Make one think twice about relying on it. What shell do you get when running Make on Windows?

While i agree, I’ve spent literal days fighting with node modules in recent months. Sure make isn’t perfect either but it’s a lot less, confusing? Ie json isn’t a language for humans, but often you really need to read it to correct some issue or bad merge from another contributor.

> Sure make isn’t perfect either but it’s a lot less, confusing?

I think that's a matter of what you're used to. I don't use make all that often, so I find make files beyond a few lines quite a lot to get my head around, whereas I spend all day writing JavaScript so I can read/write JSON in my sleep.

Maybe. I actually use node much more often, i don't even recall the last time i used a make file in production, i just find parsing json as a human to be rather painful.

http://gnuwin32.sourceforge.net/packages/make.htm

https://community.chocolatey.org/packages/make

not the point, also "WSL"

Biggest pain of package.json to me is having to be crammed on one line. Slap in a conditional and now we have a messy thing to read, compared to its multiline counterpart.

Might it not be a disservice to juniors to point them away from deeply understanding the platform they're working with?

Showing someone an alternative approach does not prevent someone "deeply understanding" their current method; it's not zero-sum.

Might it not be a disservice to juniors to point them away from deeply understanding the platform they're working with?

I cannot overstate how annoyed I was by the patronising tone of this comment.

Reply on news.ycombinator.com