Hacker News Reader

Comment by Steltek | Hacker News Reader

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.

View on HN

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

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.

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

WSL made running a linux VM less hassle.

You can put a copy of make in the repo.

For added stability, make sure it’s statically compiled (which it might be already...)

I've been using GNU Make 4.2.1 from here: https://github.com/mbuilov/gnumake-windows - depends only on kernel32.dll. I assume the latest 4.3 build there is the same.

I’m wondering if you could compile make to wasm and include it as a cross platform dev dependency?

I don't comprehend how people can develop on windows (without linux subsystem).

I have to do that every once and then (to ship the occasional C++ or Rust build on Windows) and it's the stuff of nightmare. Stuff breaking randomly from one day to another, env variables to be set in weird ways, GUI installers, 8 different versions of mingw or similar. Recently I've seen that there are a few package managers now (I used chocolatey and at least 2 others just trying to get something to compile) but still, compiling something trivial is always an adventure.

Mac OS X is kind of okay. Brew is barely decent and things mostly work (unless you discover you need to install 12GB of XCode for some dependency or your script is expecting coreutils instead of bsd).

Every linux distro comes with a package manager and compiling is trivial

> I don't comprehend how people can develop on windows

They want to distribute their app on Windows?

That’s why, not how. And you can cross-compile from Linux for some stacks.

It's easier to target Windows from Windows than from Linux.

It's usually not by choice. Medium to large enterprises often demand this so they can manage the employee hardware.

It depends a huge amount on the language and toolchain.

MSVS is really quite nice.

Homebrew is a subpar choice on macOS; MacPorts is faster, has more packages, and is implemented more correctly than Brew.

Additionally, MacPorts was co-created by an engineer who also created the original FreeBSD Ports system, and thus hews much more closely to standard UNIX/BSD practices.

I’m not sure how and when Homebrew became the standard, but it is definitively worse.

I came to realise this too.

Using Homebrew and multiple users is excruciating and an eye opener on how system-level software should really be installed.

Homebrew insists on avoiding root privileges whilst also installing packages system-wide. That works fine and is invisible with one user but falls down hard otherwise.

Their documentation is incorrect too, saying that this is all fine because “we install in /usr/local/bin”. It’s not easy to change this.

The solution was to embrace MacPorts which correctly requires root privileges to install system-wide packages.

I haven’t looked back since. I haven’t missed brew or any software that’s available on brew alone.

Too bad when I want to install newer fancy tools on Linux, it's easier to unify the environment with Homebrew instead of using Homebrew only on Linux (which has a very weird quirk that it wants to install in /home/linuxbrew/.linuxbrew (or else it'll start compiling so many packages instead rolling binary packages) instead of /opt/homebrew like any sane decision would've been.)

I also don't understand Nix when it wants to make 30 users for build process and a few unintuitive decisions. Otherwise it's good that it works same on macOS and Linux.

For me compiling usually is something like `cargo build`, `ng build`.

I remember having problems with libs that require installing & registering a library somewhere such that CMake can find it. However, I distanced myself a bit from C(++), so that doesn't really happen anymore :)

I avoid mingw, don't use any package manager besides Windows Store (if you want to call that a package manager).

Can't complain. Sometimes, there is stuff that simply doesn't support Windows -> WSL. When there is docker, it doesn't matter anyways...

My strategy is don't fight Windows and you'll be happy

From your description it sounds like you might be going off the beaten track and hitting problems.

When I was doing C++ on Windows getting a dev environment setup just meant installing Visual Studio with an appropriate Windows SDK version (or the Windows SDK + build tools for a build system).

You can have multiple VS versions installed side-by-side. To get a terminal with environment variables set correctly you just need to use the shortcuts from your VS installation.

For third party dependencies we checked the headers and (pre-built) binaries into the repository. I don’t remember ever having more than a dozen or so in total. It was usually things like boost and zlib.

Having done that you can just point CMake directly at the packages rather than worrying about FindPackage.

Working in tools like Python and Node, personally I often miss the simplicity and stability of this approach.

Are most people who would have a use for a tool like Make on Windows?

Well, most developers I work with benefit from a task runner. Now, we use different runners for different repos. I’d prefer being able to go into a repo and do «make test» and have it work, regardless of language, framework, purpose of the repo.

If you show up to the job with a windows box I expect you to know how to do the job in windows

It's the same problem with docker-compose files; how do you expect the developers not running in windows to fix your windows problems?

Thank god WSL is around. Otherwise I would've given up on supporting Windows environment for those who still stick to Windows.

If you're already using the Chocolatey package manager for Windows (I do, and am mostly happy with it), it offers GNU make:

https://community.chocolatey.org/packages/make

I have never bumped into that article before, thanks for that.

I did implement though that uniform interface in https://github.com/ysoftwareab/yplatform

And it still holds true for development today! Really any organization that has multiple languages should consider making their devs lives easier with Make.

And of course, it plays great with Docker & Compose, here's a write-up we did on using Make with container tooling: https://shipyard.build/blog/makefiles-for-modern-development...

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.

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 (disclaimer: author here) since 2016 on Linux, Mac and Windows without a problem.

That’s why you always provide an nmake for the project :)

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.

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

Nice, being able to mix them is new to me. I thought SHELL could only be set once.

Do we not have modern alternatives for make?

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

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.

It's just a nightmare to manage unless you're a Google-sized company

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

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.

Reply on news.ycombinator.com