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

331–340 of 525 posts

Re: The Makefile I use with JavaScript projects

#331

Post by hungerstrike »

gonvaled wrote: post #324
hungerstrike wrote: post #271

Earlier quoted context omitted.

This comment points out the kind of problems that can occur just on Unix systems - https://news.ycombinator.com/item?id=16485637 And then there’s Windows... Anyway, the fact that things change quickly in JS-land is more of a testament to how popular it is than anything else IMO. If C were used in the same environments as JS, I’m sure that you'd see just as much churn.

C is used in a lot of platforms. Js only in the browser (thankfully mostly converged) and in node.

JavaScript is in the server, browser, mobile apps, desktop apps and embedded devices.

Basically, it’s used everywhere that C is used and then some.

Re: The Makefile I use with JavaScript projects

#332

Post by spc476 »

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…

I was able to to it. Here's the source code "hello world.c":

    #include 
    
    int main(void)
    {
      puts("Hello, world!");
      return 0;
    }
And here's the minimal Makefile to generate the output:

    hello world:
Of course, I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) to get this to work, but hey, spaces!

Re: The Makefile I use with JavaScript projects

#333

Post by hungerstrike »

gonvaled wrote: post #323
hungerstrike wrote: post #249

Earlier quoted context omitted.

The tools are not the same on every platform. That’s reason enough for me to not use it with my JavaScript projects. The bigger reason though is that it’s not very idiomatic for JavaScript projects to use Make. It sounds like the only reason that some people go out of their way to use it is because they actually don’t want to learn something.

What is the build tool used in the javascript world this week? Broccoli? Grunt? Gulp? Talp? Just dealing with breaking changes in any one of those is a full time job!

Pro-tip: you don’t have to switch tools the minute that something new comes out.

Re: The Makefile I use with JavaScript projects

#334

Post by ljm »

scbrg wrote: post #296
oblio wrote: post #283

Earlier quoted context omitted.

You solution is a “boil the oceans” one typically proposed by engineers. You can re-program computers. You can’t re-program millions of people. Every natural language uses spaces to separate things. You can accept that or you can keep tilting at windmills. In every branch of science, reality wins. If your model can’t accomodate reality it’s either completely wrong or it needs adjustments, at least.

> Every natural language uses spaces to separate things. Exactly. To separate things. Which, incidentally, happens to also be precisely what make, and the traditional UNIX shells do :-) The problem isn't that space in itself is a particularly difficult character. The problem is that its meaning is overloaded and ambiguous. No matter what you do, computers will have difficulty with ambiguity. You'll always have the pr…

How exactly is this different to, say, maths, where there is an assumed precedence and when you need to either make that clear or change the order you use parentheses to encapsulate the inner calculation?

What it sounds like is that the Unix shell syntax was established how it was, everyone built on it with all of its syntactical conveniences, and suddenly there's 100% buy-in to the idea that a computer just can't handle a filename with spaces in a shell.

    ./cmd do-something-with --force file with spaces


    ./cmd do-something-with --force 'file with spaces'
That's one of the main problems solved. If you're expecting to run an executable with spaces in it, like this:

    ./do something with cmd --force 'file with spaces'
Then it's another problem but one that can be solved by convention. A GUI can happily execute `./do\ something\ else` but if you're in the shell you've got completions, aliases, functions, symbolic links...

And if that's not ideal, then `./'do something with' cmd …` should be good enough right?

Re: The Makefile I use with JavaScript projects

#335

Post by pcwalton »

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…

The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.

Re: The Makefile I use with JavaScript projects

#336

Post by tomn »

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…

I deal with this shape of problem quite a bit. After using scons and make in the past I recently tried using ninja, and it really works well.

Specifically, a python configure script using the ninja_syntax.py module. This seems like it's a bit more complicated, but has a lot of nice attributes.

File names with spaces should just work (unlike make). The amount of hidden complexity is very low (unlike make or SCons); all the complexity lives in your configure script. It's driven by a real, non-arcane language (unlike make). Targets are automatically rebuilt when their rules/dependencies change (unlike make).

It's more difficult to install than make, but only marginally.

Re: The Makefile I use with JavaScript projects

#337

Post by talaketu »

gonvaled wrote: post #307
debaserab2 wrote: post #209

Earlier quoted context omitted.

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.

Your tools support filenames with tabs? With any unicode char? A real world possibility.

works in bash:

> touch "withtab"

Re: The Makefile I use with JavaScript projects

#338

Post by deckard1 »

oblio wrote: post #293
markbnj wrote: post #80

Earlier quoted context omitted.

> If only whoever authored Make 40 years ago Make was created by Stuart Feldman at Bell Labs in 1976. The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Whether it is the right tool for any given modern use case is up to the people who decide to use it or pass it by. I still work with almost daily, and it's in wide use by backen…

> The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Not necessarily. > It’s also pretty much guaranteed to already be installed and working on every nix system, and that's not nothing. First mover advantage. The fact that no modern language, basically nothing outside of C/C++ uses it, says a lot. And even those are moving away,…

> basically nothing outside of C/C++ uses it

That's how it has always been, though. In the '90s you didn't need to run Perl or Tcl through it because you weren't compiling anything. The Venn diagram of "Platforms that have make" and "Popular compiled languages" comes up with only asm/C/C++.

Many languages want to do things their way, such as Erlang, Common Lisp, Java, etc. Ruby and Python are interpreted and also don't need a build process. JS, until recently, was interpreted. Lots of NIH going around.

> And even those are moving away, see Cmake & co.

Cmake is closer to autoconf/automake/libtool. If you have serious cross-platform needs, then Cmake is a fine tool. But it's hardly less archaic than make (and only slightly less so than autoconf) and I'm dubious that too many people are really moving away rather than just picking up the newer, shiny tool for newer projects.

If I were doing a small static website or something that required a build with standard *ix tools, vanilla make would be my tool of choice, hands down. Tools like autoconf and, as the author pointed out, webpack provide a more specialized need.

Re: The Makefile I use with JavaScript projects

#340

Post by bobbyi_settv »

deckard1 wrote: post #317
bobbyi_settv wrote: post #192

Earlier quoted context omitted.

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

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

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.
Post reply on HN