The Makefile I use with JavaScript projects • Hacker News Board

Re: The Makefile I use with JavaScript projects

#181

Post by nickez » Wed, Feb 28, 2018, 6:37 PM UTC

dima55 wrote: post #126

sebcat wrote: post #111

Earlier quoted context omitted.

> It actually doesn't know anything at all about how to build C, C++, or any other kind of code. I guess it depends on how you define "know", but there are implicit rules. $ cat foo.c #include int main() { printf("Hello\n"); return 0; } $ cat Makefile foo: foo.c $ make cc -O2 -pipe foo.c -o foo $ ./foo Hello

Fun fact: your Makefile above is redundant. You can delete it entirely, and the implicit rules you're using here continue to work just fine.

The built in rule to copy 'build.sh' to 'build' and make it executable is also interesting.. confused the hell out of me

Re: The Makefile I use with JavaScript projects

#182

Post by markbnj » Wed, Feb 28, 2018, 6:41 PM UTC

kowdermeister wrote: post #163

nthompson wrote: post #139

Earlier quoted context omitted.

Look at the git makefile: https://github.com/git/git/blob/master/Makefile You know what you have to do to build git? Type make. It's amazing.

If fixing things in this makefile is not your job, then it really is amazing.

Honestly its like any other tool we use: once you know the rules governing its behavior it really isn't that hard to debug issues. Make is very consistent in most cases. There are plenty of traps, and they're made easier to fall into given the archaic syntax, but you don't typically have to fall into them over and over again :).

Re: The Makefile I use with JavaScript projects

#183

Post by simias » Wed, Feb 28, 2018, 6:42 PM UTC

majewsky wrote: post #170

simias wrote: post #86

Earlier quoted context omitted.

I've been writing Makefiles regularly for maybe 15 years and I always end up on this page every time I need to write a new one: https://www.gnu.org/software/make/manual/html_node/Automatic... $ $* $^ ... Not particularly explicit. You also have the very useful substitution rules, like $(SRC:.c=.o) which are probably more arcane than they ought to be. You can make similar complaints about POSIX shell syntax but at lea…

> $(SRC:.c=.o) I use $(patsubst %.c,%.o,$(SRC)) instead, which I find easier to remember.

Isn't that a GNU extension? Here's an other problem right there, figure out which dialect of Make you're using and their various quirks and extensions.

Re: The Makefile I use with JavaScript projects

#184

Post by lisper » Wed, Feb 28, 2018, 6:44 PM UTC

ajross wrote: post #173

lisper wrote: post #158

Earlier quoted context omitted.

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. 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. That's often true for builds (which is why make works reasonably well for builds), but often not true f…

> but often not true for other kinds of workflows. Examples? I mean, there are some broken tools (EDA toolchains are famous for this) that generate multiple files with a single program run, which make can handle only with subtlety and care. But actual tasks that make manages are things that are "expensive" and require checkpointing of state in some sense (if the build was cheap, no one would bother with build tooling…

> 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).

Re: The Makefile I use with JavaScript projects

#185

Post by lisper » Wed, Feb 28, 2018, 6:45 PM UTC

derefr wrote: post #169

lisper wrote: post #158

Earlier quoted context omitted.

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. 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. That's often true for builds (which is why make works reasonably well for builds), but often not true f…

> 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?

Re: The Makefile I use with JavaScript projects

#186

Post by Jtsummers » Wed, Feb 28, 2018, 6:45 PM UTC

geezerjay wrote: post #174

lisper wrote: post #158

Earlier quoted context omitted.

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. 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. That's often true for builds (which is why make works reasonably well for builds), but often not true f…

> Make has deeply woven into it the assumption that the product of workflows are files You're referring to a standard Unix tool, an operating system where EVERYTHING is a file.

Sometimes things in workflows are sending/retrieving data over a network. It may be turning on a light. It could be changing a database. Make has no way of recognizing those events unless you've tied them to your file system. Do you really want an extra file for every entry or table in a database? It becomes fragile and error prone. A real workflow system should use a database, and not the filesystem-as-database.

Re: The Makefile I use with JavaScript projects

#187

Post by lisper » Wed, Feb 28, 2018, 6:45 PM UTC

geezerjay wrote: post #174

lisper wrote: post #158

Earlier quoted context omitted.

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. 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. That's often true for builds (which is why make works reasonably well for builds), but often not true f…

> Make has deeply woven into it the assumption that the product of workflows are files You're referring to a standard Unix tool, an operating system where EVERYTHING is a file.

But it's not true that everything is a file. A row in a relational database, for example, is not a file, even in unix.

Re: The Makefile I use with JavaScript projects

#188

Post by ethagnawl » Wed, Feb 28, 2018, 6:48 PM UTC

mauvehaus wrote: post #93

ethagnawl wrote: post #33

Earlier quoted context omitted.

If you're able, I'd be very interested in seeing some examples.

Not the OP, doing a bit less that it sounds like the OP is doing, but we built out a relatively handy make-based build system for building a set of images in correct dependency order. Another member of the team subsequently taught make about the reverse dependencies so that you can split jobs across Travis nodes by the top-ish level image they depend on. My favorite addition was the ability to generate a dependency g…

Thanks for chiming in. That all sounds very interesting and this thread has got my gears turning.

I regret not considering Make for Docker administration months/years ago. I've taken to using bash scripts or, worse, tagged bash comments to recall commonly used complex commands.

Re: The Makefile I use with JavaScript projects

#189

Post by ajross » Wed, Feb 28, 2018, 6:49 PM UTC

lisper wrote: post #184

ajross wrote: post #173

Earlier quoted context omitted.

> but often not true for other kinds of workflows. Examples? I mean, there are some broken tools (EDA toolchains are famous for this) that generate multiple files with a single program run, which make can handle only with subtlety and care. But actual tasks that make manages are things that are "expensive" and require checkpointing of state in some sense (if the build was cheap, no one would bother with build tooling…

> 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'd be very curious to hear about systems that have successfully done this. As just a general design point, storing clearly derived data (it's build output from "source" files!) in a database is generally considered bad form. It also introduces the idea of an outside dependency on a build, which is also bad form (the "source" code isn't enough anymore, you need a deployed system out there somewhere also).

Re: The Makefile I use with JavaScript projects

#190

Post by xaedes » Wed, Feb 28, 2018, 6:50 PM UTC

jayshua wrote: post #74

The concepts behind make are quite good, but the interface it provides is not decidedly not. It reminds me of Git in that respect. I'd think replacing the opaque symbols used everywhere with more descriptive words would be helpful. I don't suppose anyone knows if modern Make versions support alternatives to $@, $%, $?, etc. that can be read rather than memorized?

You _could_ do something like this:

   make -f-


But for the sake of compatibility I wouldn't.


    
      Permalink
      View on HN
      Reply on HN
      Top