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

131–140 of 525 posts

Re: The Makefile I use with JavaScript projects

#131

Post by afranchuk »

I have used make for years and am very familiar with it. My two major complaints are:

1. The assumptions that it makes. Everything in and out are files (phony files notwithstanding). It is hard and painful if you want outputs to rely on and rebuild from configuration in the makefile itself. It's not impossible to implement, but it's difficult to precisely implement it: often times I've seen systems that just rebuild everything after configuration changes.

2. The mix of declarative and imperative styles, while useful for quickly throwing a build together, gets difficult to deal with as things scale up. The make language itself is pretty restricted, too (without using $(eval)).

I know that recent versions support guile extensions and even C(/C++?) extensions, but at that point it's not giving you all that much. I have often wished the make functionality was exposed in some "libmake" for me to extend.

For this reason (and others), I've recently refactored a huge build system to use shake[1] instead. Now builds are precise and correct, and properly depend on configuration and build environment.

[1]: https://shakebuild.com/

Re: The Makefile I use with JavaScript projects

#132

Post by falcolas »

MaulingMonkey wrote: post #108
falcolas wrote: post #72

Earlier quoted context omitted.

Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. Incremental builds by looking for changed dependencies, a configuration file with its own significant identifiers (i.e. a build DSL shoehorned into JSON or YAML), generalized target rules, shelling out commands, sub-project builds, dry runs, dependencies for your own script, parallelization, and a…

> Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection iss…

I'd argue that there are some major concerns with the makefiles if they require the use of 3 different versions of make to get it all working - a situation I've never personally seen before. I'd suggest prioritizing fixing that before attempting tracking down the cause of other issues. As it stands, there are too many points of interaction to attribute any bugs to any one program.

That said, Windows has never been a strong platform on which to run make (or git, gcc, or any other [u/li]nix originated CLI tools). When I hear of folks using make, I tend to make the assumption that they're running on a [u/li]nix or BSD derivative.

Re: The Makefile I use with JavaScript projects

#133

Post by jlg23 »

The author forgot some great features of make:

* Parallel execution of build rules comes for free in a lot of implementations. This is really noticeable when you do heavy asset pre-processing.

* Cleanly written build rules are re-usable across projects as long as those projects have the same structure (directory layout).

* Cleanly written build rules provide incremental compilation/assembly for free: You express intermediate steps as targets and those are "cached". I put the "cached" in quotes here, because you essentially define a target file which is regenerated when it's dependencies are updated. Additional benefit: Inspection of intermediate results is easy - they are sitting there as files right in your build's output tree.

Re: The Makefile I use with JavaScript projects

#134

Post by mmjaa »

cat199 wrote: post #129
mmjaa wrote: post #125

Earlier quoted context omitted.

foldoc.org is the product of a single individuals' construction of definitions of computing terms and is by no means a complete and authoritative source of technical terms. It says so right there on the site... However, this is a fun game, so lets play: http://www.yourdictionary.com/transpiler https://en.wiktionary.org/wiki/transpiler https://www.thefreedictionary.com/transpiler https://www.quora.com/What-is-a-transp…

please feel free to attribute or posit another source w/r/t etymology within computing, I'm all ears. I doubt you'll find 'transpiler' at the origins of computing history; see also C++/cfront post

4 refs in my post, check it. You won't find "full stack development" in the roots of computing history either; language is malleable and useful. Get over it.

Re: The Makefile I use with JavaScript projects

#135

Post by sebcat »

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.

That doesn't work for me. Tried with empty Makefile, no Makefile, with make (PMake) and gmake (GNU Make).

Re: The Makefile I use with JavaScript projects

#136

Post by rschloming »

peterwwillis wrote: post #121
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

Yeah. There is a metric crap-ton of the design of Make that is solely for the purpose of compiling and linking and document processing. That's actually part of what makes it annoying to use it for projects other than C or C++, when you don't need to compile or transform or depend on different formats.

The core of make is really just a control flow model that understands file dependencies as a first class thing, and permits arbitrary user supplied actions to be specified to update those files. All those default rules around how to handle C files are really more like a standard library and can be easily overridden as desired.

IMHO what makes it annoying for projects other than C or C++ is that there isn't an equivalent portion of makes "standard library" that applies to e.g. java, but this is largely because java went down a different path to develop its build ecosystem.

In an alternate reality java tooling might have been designed to work well with make, and then make would have a substantial builtin knowledge base around how to work with java artifacts as well as having a really nice UX for automating custom workflows, but instead java went down the road of creating monolithic build tooling and for a long time java build tooling really sucked at being extensible for custom workflows.

Re: The Makefile I use with JavaScript projects

#137

Post by mhei »

sebcat wrote: post #135
dima55 wrote: post #126

Earlier quoted context omitted.

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.

That doesn't work for me. Tried with empty Makefile, no Makefile, with make (PMake) and gmake (GNU Make).

Try "make foo" instead of "make"

Re: The Makefile I use with JavaScript projects

#138

Post by emmelaich »

jschwartzi wrote: post #70
jrimbault wrote: post #43

Earlier quoted context omitted.

They must have got something good though. Else why would there entire families of C-like languages ? Plus, to me C syntax is particularly good. You're writing real words and the computers does the things you tell it to. To the letter.

The nice thing about C is that it's a great cross-platform assembly language. I wouldn't call its syntax good or bad.

Exactly. If C hadn't been invented then someone would have invented it later under a different name.

Because it's obvious people need a minimalistic portable assembler.

Re: The Makefile I use with JavaScript projects

#139

Post by nthompson »

markbnj wrote: post #80
rectang wrote: post #23

Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design acumen of a Ken Thompson or a Dennis Ritchie! We're stuck with Make because of network effects. I wish that it could just become "lost" forever and a different dependency-based-programming build tool could replace it... but that's just wishful thinking. The pace o…

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

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.

Re: The Makefile I use with JavaScript projects

#140

Post by kstrauser »

jstimpfle wrote: post #90
jimktrains2 wrote: post #71

Earlier quoted context omitted.

> They must have got something good though. Else why would there entire families of C-like languages ? Network effect. If you wanted to write for unix, you almost had to use C originally. > Plus, to me C syntax is particularly good. It's meh. It's not the most straightforward when defining complex types like arrays or function pointers. > You're writing real words and the computers does the things you tell it to. To…

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.

Post reply on HN