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...
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...
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).
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
They want to distribute their app on Windows?
MSVS is really quite nice.
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.
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.
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.
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
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.
It's the same problem with docker-compose files; how do you expect the developers not running in windows to fix your windows problems?
I did implement though that uniform interface in https://github.com/ysoftwareab/yplatform