4 ms·

You did the right thing. Software should be built using fundamental tools and not frameworks and libraries that are here for the next two years. Make is never g

You did the right thing. Software should be built using fundamental tools and not frameworks and libraries that are here for the next two years. Make is never going away, it's so fundamental that we'll be using it in 20 years.

Silhouette 11y ago
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.
- voltagex_ 11y ago
  I've got to disagree. After dealing with npm and grunt in an enterprise environment, MSBuild, Make and CMake start to look very very attractive.
  - Silhouette 11y ago
    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.
    - voltagex_ 11y ago
      Well yeah, but continuing to use npm might be Stockholm Syndrome at this point!
      - nilliams 11y ago
        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'. [0] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
- nwmcsween 11y ago
  Make is actually really simple the problem is people approach it like an imperative programming language.
  - Silhouette 11y ago
    You and I have very different definitions of "really simple", I think. The manual for GNU Make contains around 80,000 words. That is roughly the length of an average novel.
    - nwmcsween 11y ago
      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.
- 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?

Silhouette 11y ago

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.

voltagex_ 11y ago
I've got to disagree. After dealing with npm and grunt in an enterprise environment, MSBuild, Make and CMake start to look very very attractive.
- Silhouette 11y ago
  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.
  - voltagex_ 11y ago
    Well yeah, but continuing to use npm might be Stockholm Syndrome at this point!
    - nilliams 11y ago
      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'. [0] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
nwmcsween 11y ago
Make is actually really simple the problem is people approach it like an imperative programming language.
- Silhouette 11y ago
  You and I have very different definitions of "really simple", I think. The manual for GNU Make contains around 80,000 words. That is roughly the length of an average novel.
  - nwmcsween 11y ago
    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.
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?