4 ms·

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

by dozzie 11y ago

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

Silhouette 11y ago
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.
- dozzie 11y ago
  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.
  - Silhouette 11y ago
    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. How would you set Make up to solve this problem?
    - dozzie 11y ago
      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: rm -f $(filter-out $(EXPECTED),$(FOUND))
      - Silhouette 11y ago
        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.

by dozzie 11y ago

Silhouette 11y ago

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.

dozzie 11y ago
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.
- Silhouette 11y ago
  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. How would you set Make up to solve this problem?
  - dozzie 11y ago
    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: rm -f $(filter-out $(EXPECTED),$(FOUND))
    - Silhouette 11y ago
      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.