5 ms·

After going through a few build systems for Javascript, I realized they were all reinventing the wheel in one way or the other, and pulled out venerable Make fr

After going through a few build systems for Javascript, I realized they were all reinventing the wheel in one way or the other, and pulled out venerable Make from the closet. It turned out to be way more expressive and easy to read. One target to build (prod), another to run with fsevents doing auto-rebuild when a file is saved (instant gratification during dev), then a few targets for cleaup & housekeeping. All said, the file is 1/4 the size of any other JS-based build systems.

IshKebab 9y ago
Wow if you consider Makefiles easy to read...
- gnclmorais 9y ago
  I’ve written about Makefiles for the web before, you can’t say they can’t be readable: http://blog.gnclmorais.com/makefiles-are-for-the-web http://blog.gnclmorais.com/makefiles-are-for-the-web
  - jorams 9y ago
    Something about the Makefile in your post is a bit weird though: You only declare "test" as a PHONY target, but every other target in the file is just as PHONY. And since you don't even explain that line, it could be a bit confusing.
- bpicolo 9y ago
  Simple makefiles couldn't be more simple. task: dependency list of commands That's about as easy as it gets.
  - bitwize 9y ago
    Until a stray space finds its way into your command list indentation...
    - bpicolo 9y ago
      Every popular text editor handles this already. People manage make, python and other whitespace-specified languages just fine.
      - emmelaich 9y ago
        They don't though. Vanilla Vim/Vi doesn't for instance. Regardless of whether the editor can or not, I just don't see how insisting on tab and not space is remotely defensible.
        bpicolo 9y ago
        https://stackoverflow.com/a/29787362 https://stackoverflow.com/a/29787362 > remotely defensible Feel free to write your own make superset that supports spaces. It's an irrelevant factor to the usability of make as a whole.
        emmelaich 9y ago
        It's something that almost everyone trips over. Multiple times. Actually writing a preprocessor for Make sounds like a pretty good idea.
        voltagex_ 9y ago
        ninja, cmake, premake.
        deathanatos 9y ago
        > Vanilla Vim/Vi doesn't for instance. Vim does handle this. Here is Vim (and I've removed my .vimrc file, so this is not a setting I have set personally), on a Makefile where the third line erroneously uses spaces: https://i.imgur.com/xMHXeL4.png https://i.imgur.com/xMHXeL4.png > I just don't see how insisting on tab and not space is remotely defensible. This is like insisting that people haven't been having religious wars over this sort topic for years. You can see the Wiki[1] page on it (which starts "This is one of the eternal Holy Wars") for arguments as to why someone might prefer tabs. I personally like them because they allow the reader of the code to choose the visual layout of the indentation. Now, while I love tabs, I work in Python all day. But good editors, like Vim, allow you to customize the indentation settings sufficiently to handle both cases like Python (spaces for indent) and Makefile (tabs) gracefully. So "Indent" and "Dedent" just do The Right Thing™ and it mostly never matters. [1]: http://wiki.c2.com/?TabsVersusSpaces http://wiki.c2.com/?TabsVersusSpaces
  - matheusmoreira 9y ago
    Real world makefiles are not simple like this. The simplest makefile I can think of is still hundreds of lines long: https://git.musl-libc.org/cgit/musl/tree/Makefile https://git.musl-libc.org/cgit/musl/tree/Makefile
    - creatornator 9y ago
      Maybe this isn't "real-world" but I've made this cookiecutter template which generates projects with Makefiles less than 100 lines. It works decently well for my personal projects and for playing around. https://github.com/MatanSilver/cookiecutter-cproj https://github.com/MatanSilver/cookiecutter-cproj
- tachyoff 9y ago
  It's certainly better than the 200+ lines of JavaScript something like Webpack spits out when you statr a new project. I had to debug some of our project's build files and realized halfway through that my teammates didn't write this Webpack config monstrosity, Webpack generated it by /default/.
  - acemarke 9y ago
    Webpack, by itself, doesn't generate configs, unless you're referring to the Webpack CLI tool. FWIW, Webpack 4 (which just went final a few days ago) now has "zero-config" defaults out of the box. You may want to give that a shot.
    - tachyoff 9y ago
      Eh, I tend towards “let’s not touch this if it works”. I’ve already had to upgrade from Webpack 1 to 2, and 2 to 3. If it ain’t broke, don’t fix it.
      - acemarke 9y ago
        Sure, I can sympathize. That said, I've seen a bunch of "here's my results after upgrading to Webpack 4" tweets going around, and they all indicate much faster builds and somewhat smaller bundle sizes, with very minimal config changes needed.
- megaman22 9y ago
  Next to a non-toy webpack or gulp configuration, makefiles are pretty clean and simple.
bobbyi_settv 9y ago
The reason I don't like doing this is portability. Since the steps within the makefile are going to be run through a shell, it is going to behave differently on different systems. If your makefile fixes up a file using sed and your system has gnu sed, your makefile may fail on a system with BSD sed (e.g., a mac). If you rely on bash-isms, your makefile may not work on a debian system where it will be run with dash instead of bash. And so on.
- athenot 9y ago
  True but I should specify that my targets do the job in 1 to 3 lines. No magic bash. Also, I use javascript where it makes sense: I rely on Browserify to resolve the web of `require`d files.
- deckard1 9y ago
  I say, you JS guys doth protest a bit too much. If you look in your package.json, you'll surely see a dozen or so "scripts" lines that run through the same shell that make does and have all the problems you just mentioned. I'd also like to point out that Linux and almost certainly your production environment (because it's most likely *ix) will be case sensitive. Your macOS or Windows file system? Not so much. Point is, you're already up to your neck in portability issues. My macOS coworkers often forget this detail.
  - bobbyi_settv 9y ago
    If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere.
    - deckard1 9y ago
      > That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere. huh?? No it's not. That's the whole discussion we are having now. I even specifically mentioned my macOS coworkers who develop on their Mac and are oblivious to case-sensitivity issues. Because "it worked for me." > If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. Oh, I'd love for that to be true. But also not what I was referring to. Most large projects have a "scripts" section and those are no different than Makefile commands. If you're paranoid about your own Makefiles then you're going to need to be paranoid about your own package.json.
fiatjaf 9y ago
Not to mention that gulp, grunt (do people still use this?) and webpack configs are written in JavaScript, so they're likely to have very hard to debug errors in them on the first 5 revisions.
- lpghatguy 9y ago
  The errors shouldn't be any harder to debug than the program itself after 5 revisions.

IshKebab 9y ago

Wow if you consider Makefiles easy to read...

gnclmorais 9y ago
I’ve written about Makefiles for the web before, you can’t say they can’t be readable: http://blog.gnclmorais.com/makefiles-are-for-the-web http://blog.gnclmorais.com/makefiles-are-for-the-web
- jorams 9y ago
  Something about the Makefile in your post is a bit weird though: You only declare "test" as a PHONY target, but every other target in the file is just as PHONY. And since you don't even explain that line, it could be a bit confusing.
bpicolo 9y ago
Simple makefiles couldn't be more simple. task: dependency list of commands That's about as easy as it gets.
- bitwize 9y ago
  Until a stray space finds its way into your command list indentation...
  - bpicolo 9y ago
    Every popular text editor handles this already. People manage make, python and other whitespace-specified languages just fine.
    - emmelaich 9y ago
      They don't though. Vanilla Vim/Vi doesn't for instance. Regardless of whether the editor can or not, I just don't see how insisting on tab and not space is remotely defensible.
      - bpicolo 9y ago
        https://stackoverflow.com/a/29787362 https://stackoverflow.com/a/29787362 > remotely defensible Feel free to write your own make superset that supports spaces. It's an irrelevant factor to the usability of make as a whole.
        emmelaich 9y ago
        It's something that almost everyone trips over. Multiple times. Actually writing a preprocessor for Make sounds like a pretty good idea.
        voltagex_ 9y ago
        ninja, cmake, premake.
      - deathanatos 9y ago
        > Vanilla Vim/Vi doesn't for instance. Vim does handle this. Here is Vim (and I've removed my .vimrc file, so this is not a setting I have set personally), on a Makefile where the third line erroneously uses spaces: https://i.imgur.com/xMHXeL4.png https://i.imgur.com/xMHXeL4.png > I just don't see how insisting on tab and not space is remotely defensible. This is like insisting that people haven't been having religious wars over this sort topic for years. You can see the Wiki[1] page on it (which starts "This is one of the eternal Holy Wars") for arguments as to why someone might prefer tabs. I personally like them because they allow the reader of the code to choose the visual layout of the indentation. Now, while I love tabs, I work in Python all day. But good editors, like Vim, allow you to customize the indentation settings sufficiently to handle both cases like Python (spaces for indent) and Makefile (tabs) gracefully. So "Indent" and "Dedent" just do The Right Thing™ and it mostly never matters. [1]: http://wiki.c2.com/?TabsVersusSpaces http://wiki.c2.com/?TabsVersusSpaces
- matheusmoreira 9y ago
  Real world makefiles are not simple like this. The simplest makefile I can think of is still hundreds of lines long: https://git.musl-libc.org/cgit/musl/tree/Makefile https://git.musl-libc.org/cgit/musl/tree/Makefile
  - creatornator 9y ago
    Maybe this isn't "real-world" but I've made this cookiecutter template which generates projects with Makefiles less than 100 lines. It works decently well for my personal projects and for playing around. https://github.com/MatanSilver/cookiecutter-cproj https://github.com/MatanSilver/cookiecutter-cproj
tachyoff 9y ago
It's certainly better than the 200+ lines of JavaScript something like Webpack spits out when you statr a new project. I had to debug some of our project's build files and realized halfway through that my teammates didn't write this Webpack config monstrosity, Webpack generated it by /default/.
- acemarke 9y ago
  Webpack, by itself, doesn't generate configs, unless you're referring to the Webpack CLI tool. FWIW, Webpack 4 (which just went final a few days ago) now has "zero-config" defaults out of the box. You may want to give that a shot.
  - tachyoff 9y ago
    Eh, I tend towards “let’s not touch this if it works”. I’ve already had to upgrade from Webpack 1 to 2, and 2 to 3. If it ain’t broke, don’t fix it.
    - acemarke 9y ago
      Sure, I can sympathize. That said, I've seen a bunch of "here's my results after upgrading to Webpack 4" tweets going around, and they all indicate much faster builds and somewhat smaller bundle sizes, with very minimal config changes needed.
megaman22 9y ago
Next to a non-toy webpack or gulp configuration, makefiles are pretty clean and simple.

bobbyi_settv 9y ago

The reason I don't like doing this is portability. Since the steps within the makefile are going to be run through a shell, it is going to behave differently on different systems. If your makefile fixes up a file using sed and your system has gnu sed, your makefile may fail on a system with BSD sed (e.g., a mac). If you rely on bash-isms, your makefile may not work on a debian system where it will be run with dash instead of bash. And so on.

athenot 9y ago
True but I should specify that my targets do the job in 1 to 3 lines. No magic bash. Also, I use javascript where it makes sense: I rely on Browserify to resolve the web of `require`d files.
deckard1 9y ago
I say, you JS guys doth protest a bit too much. If you look in your package.json, you'll surely see a dozen or so "scripts" lines that run through the same shell that make does and have all the problems you just mentioned. I'd also like to point out that Linux and almost certainly your production environment (because it's most likely *ix) will be case sensitive. Your macOS or Windows file system? Not so much. Point is, you're already up to your neck in portability issues. My macOS coworkers often forget this detail.
- bobbyi_settv 9y ago
  If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere.
  - deckard1 9y ago
    > That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere. huh?? No it's not. That's the whole discussion we are having now. I even specifically mentioned my macOS coworkers who develop on their Mac and are oblivious to case-sensitivity issues. Because "it worked for me." > If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. Oh, I'd love for that to be true. But also not what I was referring to. Most large projects have a "scripts" section and those are no different than Makefile commands. If you're paranoid about your own Makefiles then you're going to need to be paranoid about your own package.json.

fiatjaf 9y ago

Not to mention that gulp, grunt (do people still use this?) and webpack configs are written in JavaScript, so they're likely to have very hard to debug errors in them on the first 5 revisions.

lpghatguy 9y ago
The errors shouldn't be any harder to debug than the program itself after 5 revisions.