7 ms·

This seems to be missing the obvious point: Make isn't anchored to any single language. If you will only ever use npm for your entire life, then you go ahead an

This seems to be missing the obvious point: Make isn't anchored to any single language. If you will only ever use npm for your entire life, then you go ahead an live happily in package.json script land. But I've lost track of the number of languages and environments that I've worked in. Make ties it together by being the Good Enough anchor point that documents and launches all the other tools and compilers. - Compile this Rust app with Cargo then flash it to the esp32? Make. - Build this page with JS using Tool Of The Week and push it to a test container? Make. - Compile ancient C app and build a .deb? Make. And so on. Why not use shell scripts you may ask? Because shell scripts are way too free form and your tastes will change over time. Make forces just enough structure that you won't get carried away with yourself. Not for the basic task running stuff anyway.

dongping 5y ago
Bazel would be a better solution in terms of reproducibility and user-friendliness, though.
- nuccy 5y ago
  I agree, but make is usually more abundant on much more systems (which is useful when there is no root privileges available). Also people are used to run make when they encounter a Makefile. I personally use Makefiles even to create Docker images, I find it simpler to run make images or make run, than remembering (or putting in a script and remember what parameters to use, as pointed in the comment above scripts are too free-style) how to do it manually. Though I also agree that Makefile is not a silver bullet and some more complex/niche methods may be required in particular cases.
- physicsguy 5y ago
  It's just a nightmare to manage unless you're a Google-sized company
  - klodolph 5y ago
    I've been working with Bazel by myself. My experience is that it is not a nightmare... it's just the documentation is missing some pretty crucial "how-to" guides, and there are a couple features that changed a lot prior to 1.0 (so using them is a bit difficult). Some stuff that is very easy with makefiles is a bit harder with Bazel, so I can't give it an unqualified recommendation. The payoff is that some things that are very, very hard with makefiles are much easier with Bazel (using multiple languages, cross-compiling, downloading dependencies automatically, distributed builds, etc).
    - physicsguy 5y ago
      My experience is mostly through consuming packages that other people have written, and the downloading existing packages is a big part of why it's problematic. If I already have PrettyCommonStandardLibraryX, I don't really want Bazel to download another copy of it for me just to incorporate your project. Other build systems are simple enough to change, or support this straightforwardly. Doing it with Bazel is quite painful IMO.
kemenaran 5y ago
I like nothing more than dropping into a new project, and, rather than figuring out the commands to make it run, see that it has a Makefile with a handful of targets for common tasks. With some collegues we wrote an article about the benefits of this approach a few years ago: https://blog.capitaines.fr/2016/09/30/standardizing-interfaces-across-projects-with-makefiles/ https://blog.capitaines.fr/2016/09/30/standardizing-interfac...
- pletnes 5y ago
  I could not agree more. However most people are on windows for which obtaining gnu make is painful, or maybe even impossible - at least the path handling has many sharp edges.
  - kemenaran 5y ago
    Indeed – although I guess WSL made unix tools slightly easier to use nowadays. But even without executing the Makefile, simply reading it can tell new developers which language-specific command needs to be run to build the project (and then the command can be copy-pasted and run manually).
    - pletnes 5y ago
      WSL made running a linux VM less hassle.
  - tom_ 5y ago
    You can put a copy of make in the repo.
    - matt123456789 5y ago
      For added stability, make sure it’s statically compiled (which it might be already...)
      - tom_ 5y ago
deleted 5y ago
[deleted]
slaymaker1907 5y ago
The only bad part about Make is that it doesn't provide even the most basic utilities for doing cross platform work like removing a directory. It mostly works with Unix, but writing a Makefile that works on Windows and Unix is really hard. If Make had just a few more batteries included, it would be perfect. However, maybe adding those batteries would take away from its other qualities.
- andreineculau 5y ago
  Nowadays there's Windows Subsystem for Linux. There's no excuse not to successfully run "Linux" scripts on Windows. I've been running very complex build systems via https://github.com/ysoftwareab/yplatform https://github.com/ysoftwareab/yplatform (disclaimer: author here) since 2016 on Linux, Mac and Windows without a problem.
- metaltyphoon 5y ago
  That’s why you always provide an nmake for the project :)
- Izkata 5y ago
  Make is a file-based dependency tree that only defaults to a specific shell. If you really want to go crazy, you could actually change it to anything that can be invoked with "<executable> <file>", such as python, and use that language instead. As a really crude example: SHELL := python .ONESHELL: out.csv: import csv with open("$@", "w") as f: writer = csv.writer(f) writer.writerow(["header1", "header2"]) and so: $ make import csv with open("out.csv", "w") as f: writer = csv.writer(f) writer.writerow(["header1", "header2"]) $ cat out.csv header1,header2 I get that this doesn't exactly solve your "cross-platform work" gripe, but my point is that a lot of what people perceive as make providing isn't actually make in the first place.
  - pqb 5y ago
    Thank you for reminding me it! Awesome finding. Worth noting, each recipe can have its very own SHELL[0] (e.g., ruby recipe, that uses ruby command with -e flag): ruby: .SHELLFLAGS := -e ruby: SHELL := ruby ruby: greeting = "labas" puts "#{greeting}, ruby!" [0]: http://agdr.org/2020/05/14/Polyglot-Makefiles.html http://agdr.org/2020/05/14/Polyglot-Makefiles.html

dongping 5y ago

Bazel would be a better solution in terms of reproducibility and user-friendliness, though.

nuccy 5y ago
I agree, but make is usually more abundant on much more systems (which is useful when there is no root privileges available). Also people are used to run make when they encounter a Makefile. I personally use Makefiles even to create Docker images, I find it simpler to run make images or make run, than remembering (or putting in a script and remember what parameters to use, as pointed in the comment above scripts are too free-style) how to do it manually. Though I also agree that Makefile is not a silver bullet and some more complex/niche methods may be required in particular cases.
physicsguy 5y ago
It's just a nightmare to manage unless you're a Google-sized company
- klodolph 5y ago
  I've been working with Bazel by myself. My experience is that it is not a nightmare... it's just the documentation is missing some pretty crucial "how-to" guides, and there are a couple features that changed a lot prior to 1.0 (so using them is a bit difficult). Some stuff that is very easy with makefiles is a bit harder with Bazel, so I can't give it an unqualified recommendation. The payoff is that some things that are very, very hard with makefiles are much easier with Bazel (using multiple languages, cross-compiling, downloading dependencies automatically, distributed builds, etc).
  - physicsguy 5y ago
    My experience is mostly through consuming packages that other people have written, and the downloading existing packages is a big part of why it's problematic. If I already have PrettyCommonStandardLibraryX, I don't really want Bazel to download another copy of it for me just to incorporate your project. Other build systems are simple enough to change, or support this straightforwardly. Doing it with Bazel is quite painful IMO.

kemenaran 5y ago

I like nothing more than dropping into a new project, and, rather than figuring out the commands to make it run, see that it has a Makefile with a handful of targets for common tasks. With some collegues we wrote an article about the benefits of this approach a few years ago: https://blog.capitaines.fr/2016/09/30/standardizing-interfaces-across-projects-with-makefiles/ https://blog.capitaines.fr/2016/09/30/standardizing-interfac...

pletnes 5y ago
I could not agree more. However most people are on windows for which obtaining gnu make is painful, or maybe even impossible - at least the path handling has many sharp edges.
- kemenaran 5y ago
  Indeed – although I guess WSL made unix tools slightly easier to use nowadays. But even without executing the Makefile, simply reading it can tell new developers which language-specific command needs to be run to build the project (and then the command can be copy-pasted and run manually).
  - pletnes 5y ago
    WSL made running a linux VM less hassle.
- tom_ 5y ago
  You can put a copy of make in the repo.
  - matt123456789 5y ago
    For added stability, make sure it’s statically compiled (which it might be already...)
    - tom_ 5y ago

deleted 5y ago

[deleted]

slaymaker1907 5y ago

The only bad part about Make is that it doesn't provide even the most basic utilities for doing cross platform work like removing a directory. It mostly works with Unix, but writing a Makefile that works on Windows and Unix is really hard. If Make had just a few more batteries included, it would be perfect. However, maybe adding those batteries would take away from its other qualities.

andreineculau 5y ago
Nowadays there's Windows Subsystem for Linux. There's no excuse not to successfully run "Linux" scripts on Windows. I've been running very complex build systems via https://github.com/ysoftwareab/yplatform https://github.com/ysoftwareab/yplatform (disclaimer: author here) since 2016 on Linux, Mac and Windows without a problem.
metaltyphoon 5y ago
That’s why you always provide an nmake for the project :)
Izkata 5y ago
Make is a file-based dependency tree that only defaults to a specific shell. If you really want to go crazy, you could actually change it to anything that can be invoked with "<executable> <file>", such as python, and use that language instead. As a really crude example: SHELL := python .ONESHELL: out.csv: import csv with open("$@", "w") as f: writer = csv.writer(f) writer.writerow(["header1", "header2"]) and so: $ make import csv with open("out.csv", "w") as f: writer = csv.writer(f) writer.writerow(["header1", "header2"]) $ cat out.csv header1,header2 I get that this doesn't exactly solve your "cross-platform work" gripe, but my point is that a lot of what people perceive as make providing isn't actually make in the first place.
- pqb 5y ago
  Thank you for reminding me it! Awesome finding. Worth noting, each recipe can have its very own SHELL[0] (e.g., ruby recipe, that uses ruby command with -e flag): ruby: .SHELLFLAGS := -e ruby: SHELL := ruby ruby: greeting = "labas" puts "#{greeting}, ruby!" [0]: http://agdr.org/2020/05/14/Polyglot-Makefiles.html http://agdr.org/2020/05/14/Polyglot-Makefiles.html