Hacker News Reader

Comment by nawitus | Hacker News Reader

Make uses disk I/O, which is really slow, and for complex projects become difficult to maintain. Also, why not use a proper programming language to define the build process? Well, a modern tool like Gulp[1] does that. It's streaming/asynchronous and scripts are written in JavaScript. I don't see why one would prefer Make over it.

1. https://github.com/gulpjs/gulp

View on HN

There are many complex projects that use Make to build source code. Grab just about any software release tarball and there will almost certainly be a Makefile in it.

This is yet another example of the JavaScript community being completely ignorant of what came before them.

I never claimed Make is not often used. My point was that there are better tools than Make available these days. If someone is starting a new project, it makes sense to check if there are alternatives to Makefiles.

I wish I could use make to build my JavaScript code, but I need it to also work on windows (easily).

If there was a version of make I could point to that would work easily on windows, preferably as a non-global variable, I would use that, until then I probably will have to use something else, through likely just bash scripting with pipes (which does work in windows).

What do you mean when you say "as a non global variable"?

The one here:

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

works fine if you do set path= and then call it using a full path into Program Files (I've just checked to make sure, but I used whatever version I had installed, not sure it's the latest one there).

I'm not defending the parent topic particularly, but it's worth noting that you're not entirely correct.

If you download any complex project, there will almost certainly be a meta makefile generator (autoconf, cmake, etc) or a set of about 30 makefiles for different various specific situations (lua, etc).

...because make is terrible at doing complex tasks on its own, and terrible at code reuse on it's own.

To be fair; async I/O isn't a magical button that makes gulp better than anything else, but it's a bit off saying an entire community is ignorant. Don't be a dick.

The important points about gulp are:

    - Better syntax
    - Plugin system (code reuse)
    - Functional programming style
    - Faster than its main alternative, grunt

shrug I wouldn't use it to build c code. ...but then again, I'd never use make to build a c project either. Ninja is significantly faster for the same low level build process.

And how exactly do you propose to compile a file without reading it?

Come on man... really... it's right there. javascript streaming asynchronous. I'm not sure how many more buzzwords you need. those earlier losers who built make, gcc, and other tools just didn't know what they were doing. And with newer tech, everyone who's not streaming asynchronous javascript is a dinosaur luddite.

I didn't propose that. The point is to read the file once, then do multiple steps on it, and write it out just once.

yeah,it's called piping and supported natively in make.

I stand corrected :).

I feel like this whole thread is a bad joke.

Do you know of Unix pipes? The fact that gulp calls all of this "streams" and "pipes" is a seriously bizarre form of NIH.

You might also be interested in make -j option.

pipes and streams mean something slightly more specify in a node context, but they are actually compatible with Unix streams, which shockingly enough also work well on windows meaning you can string together a make-like build system which works on windows as well (easily, make is not easy on windows)

Not sure what you mean. I've developed Android apps on Windows 7 using Cygwin and make just fine. It's nearly identical to using it on Linux.

You still have to install Cygwin, other solutions require no .dlls

No .dlls, just rewriting everything in Javascript. Because that's so much less invasive than a dll to let you use existing mature solutions

If only the operating system had some facility to store a recently read file in RAM, so it didn't have to read it from the disk the next time. That would be a real innovation!

(sarcasm)

Page caching: it's been around for a while. At least on unix systems. I imagine Windows, etc have it too.

I wish my compilations were merely I/O bound... everything would be so much faster then!

Well, actually they may be I/O bound.

http://aegis.sourceforge.net/auug97.pdf is old, but the problem it documents is still fairly common.

Ah, recursive make. I once spent some time trying to convert a large multiple-directory product build from many makefiles into one. Now that was painful. So many concurrency problems...

I might be wrong, but I think make does not work the way you think it does: First of all files you write to disk are not actually written to the harddrive immediately there are several caches in between, secondly if make has to process a file in multiple steps it will probably use unix pipes and won't write out intermediary files to disk.

Reply on news.ycombinator.com