It sounds like your problem with C/C++ tooling is that it's hard to support Windows. The reason for that is simply that microsoft bundles its own proprietary C++ toolchain with the platform-specific tools that Windows developers need. Windows developers don't want to install a second posix-like toolchain, and os x/bsd/linux developers don't want to install a Windows-like toolchain because in both cases the new toolchain wouldn't integrate as well with the rest of the system, and it would add unnecessary complexity to the operating system.

The problem with proper unix tools, the ones that do one thing well and integrate with other programs as a part of their design, is that they make doing cross platform work a problem, because those other programs might not exist on other platforms. GNU Make works just fine on Windows, but you're not using just make when you write a makefile. Makefiles typically depend on GNU Make, pkg-config, gcc/clang (or another compiler with the same CLI), coreutils, bourne shell, and an assortment of a few other utilities. That means that Makefiles by design will only work on a single platform.

The other operating systems have essentially made themselves into the same platform for these purposes through the use of system package managers. I've heard Windows is kind of getting one? More like homebrew than what we have in linux/bsd-land but that might still help. But maybe Windows developers will still be reluctant to install software with MinGW dependencies. That would be unfortunate, but fair; I wouldn't install a package that had Wine/Mono dependencies just because some asshole wanted to use their Windows build system on Linux! Hell, I avoid installing smaller things with a Qt or GTK3 dependency simply because none of the software I use needs those and I don't want to clutter my installed-packages list for something that isn't important.

I'm not a huge fan of Rust's Cargo. The list of requirements that the Rust team had for their package manager and build system made sense, and if I had to design a tool that met those requirements, it probably would have looked quite a bit like Cargo, but it makes me sad that the most reasonable design is that which abandons the unix-like simplicity of the python and C (and perl?) toolchains.

Of course we learned how to create good programming languages which deal with this problem. A very good and thorough approach was introduced with Modula-2, which, as the name hints to, had modules as a main focus point. Building Modula programs was an easy and quick process. The module system lives on today in the form of Golang - one of the founders was a student or Wirth.