Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Makefile I use with JavaScript projects

olioapps.com

Post reply on HN
Print view View original

191–200 of 525 posts

Re: The Makefile I use with JavaScript projects

#191

Post by makmanalp »

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…

What about, for example, a source file that needs to be downloaded and diffed from the web? What about when you need to pull stuff from a database? You can hack your way around but it's not the most fun.

Re: The Makefile I use with JavaScript projects

#192

Post by bobbyi_settv »

athenot wrote: post #6

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

Re: The Makefile I use with JavaScript projects

#193

Post by aidenn0 »

dilap wrote: post #69
aidenn0 wrote: post #64

Earlier quoted context omitted.

This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh

always been curious about redo. which variant do you use, and what do you use it for?

I use apenwar's because I installed it a long time ago and haven't needed anything more; it does look like it may be abandoned though.

I use it for anything where I need job scheduling around creating output files; even my DVD ripping is managed with redo calling into ffmpeg.

Re: The Makefile I use with JavaScript projects

#194

Post by sseth »

Jtsummers wrote: post #179
AdmiralAsshat wrote: post #116

Earlier quoted context omitted.

Isn't C just following the syntax of ALGOL? Or are we referring to the parts specific to C?

C is a simpler Algol, yes. It messed up the dangling-else problem, and lost nested procedures, among other things.

It also lost call-by-name parameters, which should be a considered a good thing.

Re: The Makefile I use with JavaScript projects

#195

Post by titanomachy »

> The target name `all` is special: When you run make with no target specified it will evaluate the `all` target by default.

This doesn't appear to be true, at least on GNU Make 3.81 (MacOS). Rather, the first target listed is the one that gets built on `make` with no arguments.

Re: The Makefile I use with JavaScript projects

#196

Post by YSFEJ4SWJUVU6 »

kstrauser wrote: post #140
jstimpfle wrote: post #90

Earlier quoted context omitted.

Everybody I know found it confusing at first, but its logical, and modular . I don't know a language with a better type declaration syntax. It gets impractical when you define function that return functions that return... because these expression grow on the left and right simultaneously. But realistically, you don't do that in C, and other than that, I find it easy to read the type of any expression... const int *x[…

> But realistically, you don't do that in C IMHO, that's a self-fulfilling prophecy. If it were reasonably easy to do that in C, it would be done more.

It is quite reasonably easy enough compared to any real practical programming task. For example:

  // your ordinary function declarations
  int plus2(int i) { return i + 2; }
  int times2(int i) { return i * 2; }

  typedef int (*modfun)(int);
  // a very reasonable syntax altogether
  modfun get_modfun(bool mul) { return (mul ? times2 : plus2); }
Nests as well if you ever wanted to:

  modfun get_modfun_no_mul(bool mul) { return plus2; }

  typedef modfun (*modfun_getter)(bool);
  modfun_getter get_getter(bool allow_mul_opt) { return (allow_mul_opt ? get_modfun : get_modfun_no_mul); }

Re: The Makefile I use with JavaScript projects

#197

Post by falcolas »

makmanalp wrote: post #191
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…

What about, for example, a source file that needs to be downloaded and diffed from the web? What about when you need to pull stuff from a database? You can hack your way around but it's not the most fun.

WRT the web file, curl can be run and only download a file if the file has been modified after the file on disk.

DB are harder (yet possible) but not a common request that I’ve seen.

Re: The Makefile I use with JavaScript projects

#198

Post by hzhou321 »

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 reasons for inflating complexities. Without rein on complexity (whether it is hidden or not), the future is doomed, whatever you are building. While I am not saying we should avoid complexity at all cost, I am insisting that all complexity should be balanced with merits.

The merits of filenames with spaces is they read better in a GUI explorer. Whether that merit balances out all the complexity it brings is individual dependent. For me, that merit ranks very low and I avoid spaces in my filenames at all opportunities. For some, they need those filenames to be readable. And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Another solution would be to add an additional pre-step of copying/renaming/linking/aliasing. With the latter solution, the complexity is confined.

I guess for some, it only matters with "I do work" or "they do work" rather than the big picture. That is fine. However given the context of you are working with Makefiles, then you are a developer at some level, you are supposed to do some work.

Re: The Makefile I use with JavaScript projects

#199

Post by enord »

lisper wrote: post #158
rschloming wrote: post #95

I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn't know anything at all about how to build C, C++, or any other kind of code. (I know this is obvious to those of us that know make, but I often get the impression that a lot of people think of make as gradle or maven for C, which it really isn't.) It's really…

> 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 regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist.

Something something username parens...

Re: The Makefile I use with JavaScript projects

#200

Post by aidenn0 »

beagle3 wrote: post #147
aidenn0 wrote: post #64

Earlier quoted context omitted.

This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh

What's your solution for mutliple-output processes like yacc/bison (which creates both an .h and a .c file?)

I don't run into those too often.

When I do, there are two cases:

1) All dependencies are on only one output file (e.g. link stages that generate .map files, compile phases that generate separate .o and debug files). I just treat these as normal

2) I may need to depend on each of the files (I don't use yacc/bison, but it sounds like this would qualify). I select one file to be the main output and have the .do file for that ensure that the secondary outputs go to a mangled name; I then have the .do files for the secondary outputs rename the mangled file.

quick example for generating foo.c/foo.h

foo.c.do:

    generate-file --cout "$3" --hout "$2-mangled.h"
foo.h.do:

    redo-ifchange "$2.c"
    mv "$2-mangled.h" "$3"
Post reply on HN