Make is never going away, it's so fundamental that we'll be using it in 20 years.
I really hope not.
There is plenty to criticise about recent build tools for web projects. Many are absurdly over-engineered. Most have very short working lives. Almost all seem to have a crazy number of dependencies of their own drawn from a fragile ecosystem.
But there is also plenty to criticise in traditional Make. The archaic and cumbersome syntax means makefiles are hard to read, analyse and maintain. The completely static nature of a makefile also means it is ill-suited to rapidly evolving codebases where new files come and go almost by the minute as we refactor. We can do much better than Make.
Actually I agree with you there. I just think that's a little like saying after watching your kid's new favourite cartoon for the sixth straight time on Christmas day, the evening family movie you first saw in 1987 starts to look very attractive.
I'm not sure what your specific gripe is with npm. It's one of the fastest and most capable package managers out there, is easily better than Python's Pip (which doesn't resolve dependencies) [0] and Go's go-get silliness for example.
If your problem is just 'lots of dependencies' that may break from under you, npm has a solution for that: 'npm shrinkwrap'.
> The completely static nature of a makefile also means it is ill-suited to rapidly evolving codebases where new files come and go almost by the minute as we refactor.
Make is so static that there was a Lisp interpreter written in make. Oh
wait...
There are several mechanisms in make to have your rules dynamically adapt to
your codebase, e.g. $(shell ...), $(wildcard ...), and pattern rules (and that's
not all of them).
You just need to put a little effort to actually read the documentation, not
just stop at finishing one of the plethora tutorials that stop after showing
variables usage.
> We can do much better than Make.
You mean, "we can do much better than my `make' knowledge". Of course we can.
Please be careful about assuming someone with a different opinion to yours is speaking from ignorance. I've been using Make for at least 20 years on a variety of projects and platforms. I'm well aware of what it can do.
Its syntax still looks like the love child of Perl and Haskell, so it is still unnecessarily difficult to write correct makefiles and to read, understand and modify existing makefiles.
But that's totally different charge than "make is static by nature, so you
need to adjust it every time you add something".
`make' may have awful syntax, though I find it much more pleasant to describe
build process than anything other on the market, most of which use general
purpose languages, ending up as terrible to read.
OK, let's look at a practical example, something that frustrates me about many current web-related tools.
Tools like Sass and Watchify can monitor for file changes and automatically regenerate SCSS or Browserify outputs when known source files are modified. They also employ caching techniques to make that regeneration efficient, instead of rebuilding everything each time. This functionality is very helpful, and it is available with a simple shell command that works on any major platform.
However, at the moment such tools typically don't notice when new source files are added and automatically start tracking them as well; this generally remains true even if the new file is imported by an existing known file. Similarly, such tools may break if a file that was being watched gets deleted.
In practice, this means you get automatic and efficient rebuilds as long as you are only changing known files, but you probably have to restart a watch process manually if you add or delete files. Fixing this would be high on my wish list for a modern web build tool, given what we already have.
First of all, I would avoid wildcards in compilation rules, using $^ instead,
so any leftovers wouldn't hurt. In the case of compilation tool being too
stupid, I would build a list of expected files out of known/present sources
($(wildcard ...), $(foreach ...), $(patsubst ...)), and then call `rm' before
calling the dumb tool:
I appreciate the reply, but unless I've completely missed your point somehow, you didn't actually answer my question there. What I'm looking for is something akin to
watchify src/index.js -o dist/index.js -t ...
or
sass --watch src/index.scss:dist/index.css
that handles new or removed files within the source tree gracefully, not just modified files that are already known when you run the command.
Whether it's monitoring for changes like these examples, or hot reloading and browser sync'ing, or IDEs that rebuild incrementally in the background so they can give immediate feedback, modern tools that actively monitor for relevant changes and respond to them automatically are noticeably more efficient to work with than traditional tools that run once on demand. Make belongs to a time that has passed, and we could be more productive by retaining the concepts that are as relevant as ever but incorporating them into tools with the more dynamic behaviour that we enjoy in other tools today.
Gnu make isnt make but it is still simple, its composed of targets and dependencies. You dont understand every detail of how say a car works yet you still drive it.
I really hope not.
There is plenty to criticise about recent build tools for web projects. Many are absurdly over-engineered. Most have very short working lives. Almost all seem to have a crazy number of dependencies of their own drawn from a fragile ecosystem.
But there is also plenty to criticise in traditional Make. The archaic and cumbersome syntax means makefiles are hard to read, analyse and maintain. The completely static nature of a makefile also means it is ill-suited to rapidly evolving codebases where new files come and go almost by the minute as we refactor. We can do much better than Make.