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

221–230 of 525 posts

Re: The Makefile I use with JavaScript projects

#221

Post by fiatjaf »

jerf wrote: post #104
jofer wrote: post #58

Earlier quoted context omitted.

Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…

"In all seriousness, what's wrong with it?" 1. Claiming a rule makes a target, but then fails to make that target, ought to be a runtime fatal error in the makefile. I can hardly even guess at how much time this one change alone would have saved people. 2. String concatenation as the fundamental composition method is a cute hack for the 1970s... no sarcasm, it really is... but there's better known ways to make "templ…

Concerning expansion, I guess the article is not claiming that it is good, it doesn't even mention this "feature". I guess it's just saying: "make can do everything your gulp can, it's better, faster and more readable", that's without using any variable expansion feature.

As soon as more JavaScript developers start writing very very simple Makefiles, tooling will improve and maybe someone will come up with a better make.

The other option is to let people keep using webpack and gulp until they come up with another JS-based build-system, webpack 5 or 6, and grulpt or whatever comes after grunt/gulp.

Re: The Makefile I use with JavaScript projects

#222

Post by hzhou321 »

debaserab2 wrote: post #209
hzhou321 wrote: post #198

Earlier quoted context omitted.

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.

What about real world is that in real world, it is not context-free. There are real world situations -- such as selling a word processor to general public (especially) including clueless -- you need to deal with files with spaces, period. But there are real world situations -- such as Makefiles -- requires users to learn the tool, to be able to handle certain tricky situations themselves and excludes incompetents. And then there are real world situations that the application only concerns within a company, or within an office, or within one-self.

What about real world is, it is complicated.

Re: The Makefile I use with JavaScript projects

#223

Post by platz »

The only build systems that I'm aware of that are monadic are redo, SCons and Shake-inspired build systems (including Shake itself, Jenga in OCaml, and several Haskell alternatives).

One realistic example (from the original Shake paper), is building a .tar file from the list of files contained in a file. Using Shake we can write the Action:

    contents
There are at least two aspects I'm aware of that increase the power of Make:

- Using `$(shell cat list.txt)` I can splice the contents of list.txt into the Makefile, reading the contents of list.txt before the dependencies are parsed.

- Using `-include file.d` I can include additional rules that are themselves produced by the build system.

It seems every "applicative" build system contains some mechanism for extending its power. I believe some are strictly less powerful than monadic systems, while others may turn out to be an encoding of monadic rules. However, I think that an explicitly monadic definition provides a clearer foundation.

http://neilmitchell.blogspot.com/2014/07/applicative-vs-mona...

Re: The Makefile I use with JavaScript projects

#224

Post by nickwanninger »

I actually usually have a general-use Makefile that I work from as a starting point [1]. It takes all c files from a src/ folder and builds their objects to build/ and then links them all in one go. No need for me to specify the files. It also works recursively.

[1]: https://pastebin.com/b1tr9th3

Re: The Makefile I use with JavaScript projects

#225

Post by radiospiel »

Jtsummers wrote: post #205
ajross wrote: post #189

Earlier quoted context omitted.

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 th…

    send: foo.log
          tail foo.log | email
          touch send

Re: The Makefile I use with JavaScript projects

#226

Post by lpghatguy »

fiatjaf wrote: post #212
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…

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.

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

Re: The Makefile I use with JavaScript projects

#227

Post by hzhou321 »

com2kid wrote: post #216
hzhou321 wrote: post #198

Earlier quoted context omitted.

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…

> 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. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one…

> Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.

That is an excellent example that deserves a second look from a different aspect.

... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.

Re: The Makefile I use with JavaScript projects

#228

Post by Zofren »

xamuel wrote: post #202
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.

What if the filename is a mixture of underscores and spaces?

Re: The Makefile I use with JavaScript projects

#229

Post by Jtsummers »

radiospiel wrote: post #225
Jtsummers wrote: post #205

Earlier quoted context omitted.

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 th…

send: foo.log tail foo.log | email touch send

Correct, that works for this example. But if you have a lot of tasks that involve non-filesystem activities you'll end up littering your filesystem with these empty files for every one of them. This can lead to its own problems (fragility, you forgot that `task_x` doesn't generate a file, or it used to generate one but no longer does, etc.).

Re: The Makefile I use with JavaScript projects

#230

Post by Jtsummers »

ajross wrote: post #219
Jtsummers wrote: post #205

Earlier quoted context omitted.

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 th…

How would you fix that with your preferred make replacement? None of that has anything to do with make, you're trying to solve a stateful problem ("did I send this or not?") without using any state. That just doesn't work. It's not a make thing at all.

Lisper was replying to the OP who suggested using Make for general workflows. Make falls apart when your workflow doesn't naturally involve file modification tasks.

With regard to my last comment (the problem with small changes in a file resulting in full-system recompilation), see Tup. It maintains a database of what's happened. So when foo.c is altered it will regenerate foo.o. But if foo.o is not changed, you can set it up to not do anything else. The database is updated to reflect that the current foo.c maps to the current foo.o, and no tasks depending on foo.o will be executed. Tup also handles the case of multiple outputs from a task. There are probably others that do this, it's the one I found that worked well for my (filesystem-based) workflows.

With regard to general workflows (that involve non-filesystem activities), you have to have a workflow system that registers when events happened and other traits to determine whether or not to reexecute all or part of the workflow.

Post reply on HN