6 ms·

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 b

by nawitus 13y ago

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 https://github.com/gulpjs/gulp

a8000 13y ago
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.
jimmaswell 13y ago
And how exactly do you propose to compile a file without reading it?
- mgkimsal 13y ago
  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.
- nawitus 13y ago
  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.
  - camus2 13y ago
    yeah,it's called piping and supported natively in make.
    - nawitus 13y ago
      I stand corrected :).
  - aryastark 13y ago
    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.
    - cwmma 13y ago
      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)
      - aryastark 13y ago
        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.
        cwmma 13y ago
        You still have to install Cygwin, other solutions require no .dlls
        pekk 13y ago
        No .dlls, just rewriting everything in Javascript. Because that's so much less invasive than a dll to let you use existing mature solutions
  - markrages 13y ago
    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)
    - gyepi 13y ago
      Page caching: it's been around for a while. At least on unix systems. I imagine Windows, etc have it too.
davexunit 13y ago
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.
- nawitus 13y ago
  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.
- cwmma 13y ago
  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).
  - maxerickson 13y ago
    What do you mean when you say "as a non global variable"? The one here: http://gnuwin32.sourceforge.net/packages/make.htm 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).
- shadowmint 13y ago
  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.
joosters 13y ago
I wish my compilations were merely I/O bound... everything would be so much faster then!
- btilly 13y ago
  Well, actually they may be I/O bound. http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf is old, but the problem it documents is still fairly common.
  - joosters 13y ago
    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...

by nawitus 13y ago

a8000 13y ago

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.

jimmaswell 13y ago

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

mgkimsal 13y ago
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.
nawitus 13y ago
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.
- camus2 13y ago
  yeah,it's called piping and supported natively in make.
  - nawitus 13y ago
    I stand corrected :).
- aryastark 13y ago
  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.
  - cwmma 13y ago
    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)
    - aryastark 13y ago
      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.
      - cwmma 13y ago
        You still have to install Cygwin, other solutions require no .dlls
        pekk 13y ago
        No .dlls, just rewriting everything in Javascript. Because that's so much less invasive than a dll to let you use existing mature solutions
- markrages 13y ago
  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)
  - gyepi 13y ago
    Page caching: it's been around for a while. At least on unix systems. I imagine Windows, etc have it too.

davexunit 13y ago

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.

nawitus 13y ago
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.
cwmma 13y ago
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).
- maxerickson 13y ago
  What do you mean when you say "as a non global variable"? The one here: http://gnuwin32.sourceforge.net/packages/make.htm 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).
shadowmint 13y ago
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.

joosters 13y ago

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

btilly 13y ago
Well, actually they may be I/O bound. http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf is old, but the problem it documents is still fairly common.
- joosters 13y ago
  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...