The Makefile I use with JavaScript projects • Hacker News Board

Re: The Makefile I use with JavaScript projects

#201

Post by fiatjaf » Wed, Feb 28, 2018, 7:09 PM UTC

make is scary because people use autogenerated Makefiles.

After you've tried to naïvely read a Makefile for a medium-sized C project you'll never want to write a Makefile yourself.

That said, there's no tool that works so simply and so beautifully as make when you have a lot of build steps that generate lots of intermediate files with complex dependency links between them. That situation may happen everywhere, even if you're generating a bunch of PDFs or rendering HTML templates or making images from .dot files or whatever. Use make.

Or is there an alternative tool for these situations also?

Re: The Makefile I use with JavaScript projects

#202

Post by xamuel » Wed, Feb 28, 2018, 7:10 PM UTC

neonscribe wrote: post #178

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…

Solution: create the pdfs with spaces replaced by underscores. Then as the very last command in the relevant makefile section, insert a bash command to replace those underscores with spaces.

Re: The Makefile I use with JavaScript projects

#203

Post by andrew_wc_brown » Wed, Feb 28, 2018, 7:10 PM UTC

hzhou321 wrote: post #198

neonscribe wrote: post #178

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…

get out of here spaces.

Re: The Makefile I use with JavaScript projects

#204

Post by dblotsky » Wed, Feb 28, 2018, 7:11 PM UTC

dmitriid wrote: post #11

lib/%: src/% mkdir -p $(dir $@) babel $ Just look at all those magic things. The percent signs! $ Well, I know they are not magic ;). But why would I want them when I can actually use normal names like "deps"/"entries" and "target"? It gets substantially worse as we go down the rabbit whole. Where webpack can easily walk the entire dependency tree by itself, we have to invoke src_files := $(shell find src/ -name '*.j…

"Doesn't cut it anymore" isn't the same as "has a different way of doing it". Make has many other (necessary) features that Webpack doesn't.

Re: The Makefile I use with JavaScript projects

#205

Post by Jtsummers » Wed, Feb 28, 2018, 7:12 PM UTC

ajross wrote: post #189

lisper wrote: post #184

Earlier quoted context omitted.

> Examples? Anything where the relevant state lives in a database, or is part of a config file, or is an event that doesn't leave a file behind (like sending a notification).

Like, for example? To be serious, those are sort of contrived. "Sending a notification" isn't something you want to be managing as state at all. What you probably mean is that you want to send that notification once, on an "official" build. And that requires storing the fact that the notification was sent and a timestamp somewhere (like, heh, a file). And as for building into a database... that just seems weird to me…

I need to send an email every time a log file updates, just the tail, simple make file:

  send: foo.log
          tail foo.log | email

  watch make send

Crap, it keeps sending it. Ok, so you work out some scheme involving temporary files which act as guards against duplicate processing. Or you write a script which conditionally sends the email by storing the hash of the previous transmission and comparing it against the hash of the new one.

That last option actually makes sense and can work well and solves a lot of problems, but you've left Make's features to pull this off. For a full workflow system you'll end up needing something more than files and timestamps to control actions, though Make can work very well to prototype it or if you only care about those timestamps.

================

Another issue with Make is that it's not smart enough to know that intermediate files may change without those changes being important. Consider that I change the comments in foo.c or reformat for some reason. This generates a new foo.o because the foo.c timestamp is updated. Now it wants to rebuild everything that uses foo.o because foo.o is newer than those targets. Problem, foo.o didn't actually change and a check of its hash would reveal that. Make doesn't know about this. So you end up making a trivial change to a source file and could spend the afternoon rebuilding the whole system because your build system doesn't understand that nothing in the binaries are actually changing.

Re: The Makefile I use with JavaScript projects

#206

Post by fiatjaf » Wed, Feb 28, 2018, 7:13 PM UTC

lisper wrote: post #185

derefr wrote: post #169

Earlier quoted context omitted.

> Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. I've always wondered whether Make would be seen as less of a grudging necessity, and more of an elegant panacea, if operating systems had gone the route of Plan 9, where everything is— symbolically —a file, even if it's not a file in the sense of "…

> everything is—symbolically—a file How are you going to make the result of a join in a relational database into a file, symbolically or otherwise?

You would probably need another query language, but that would come with time, after people had gotten used to the idea.

With that said, there are NoSQL databases these days whose query language is easily expressed as file paths. CouchDB, for example.

Re: The Makefile I use with JavaScript projects

#207

Post by dblotsky » Wed, Feb 28, 2018, 7:13 PM UTC

juliend2 wrote: post #2

One thing I've found useful about gulp and webpack is the fact that it's multiplatform. What is the best approach to make sure your Makefile will work as expected on every platform, meaning, windows included? For example: Can we write file paths using forward-slashes, or is it still an issue? I imagine running it via git bash (bash provided by the git installer on windows).

Make works on Windows. You can get it standalone, or as part of MinGW (and then even other Unix tools will work).

Re: The Makefile I use with JavaScript projects

#208

Post by dblotsky » Wed, Feb 28, 2018, 7:14 PM UTC

lowbloodsugar wrote: post #144

The problem with make is that people build makefiles such that it is later referred to as a Lost Art.

People do this with all build systems. The difference is that Grunt/Gulp/Broccoli files are a Lost Art in 3 years, and Makefiles have been around for decades.

Re: The Makefile I use with JavaScript projects

#209

Post by debaserab2 » Wed, Feb 28, 2018, 7:15 PM UTC

hzhou321 wrote: post #198

neonscribe wrote: post #178

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…

What does the merit of spaces in file names matter? You still will need to deal with files with spaces in the real world. If your tooling doesn't support it, it's a non-starter for many.

Re: The Makefile I use with JavaScript projects

#210

Post by zer00eyz » Wed, Feb 28, 2018, 7:16 PM UTC

hzhou321 wrote: post #198

neonscribe wrote: post #178

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on usi…

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as…

> At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile.

I don't understand why one would think that make would be a good tool for this...

> Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one?

Yes this is a limitation of make, but not a million other tools out there.

Make is not a panacea, no tool is - pressing a tool into a job it is un-suited for because you understand it is "Not good" (trade mark and copy right pending).

This is the classic case of having a hammer and a screw -