[kemenaran]

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

[ptrvldz]

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

[pletnes]

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.

[jokethrowaway]

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

[wwalexander]

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.

[jwdunne]

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.

[mekster]

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.

[kitkat_new]

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

[jeeeb]

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.

[Ygg2]

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

They want to distribute their app on Windows?

[pletnes]

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

[Ygg2]

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

[y4mi]

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

[JohnHaugeland]

It depends a huge amount on the language and toolchain.

MSVS is really quite nice.

[kemenaran]

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]

WSL made running a linux VM less hassle.

[arwineap]

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?

[cagey]

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

[tom_]

You can put a copy of make in the repo.

[matt123456789]

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

[tom_]

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.

[kernelsanderz]

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

[mekster]

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

[leephillips]

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

[pletnes]

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.

[andreineculau]

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

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