Advice to young devs: If you don't have a good professional reason why you absolutely need to use gnu tools on windows, and you have no technical reason not to use Visual Studio, use Visual Studio. It's good enough, and for me, even good.
I dislike Visual Studio because to set things up you have to compare online screenshots to your settings and click around multiple tabs of configurations. In the end you (as beginner) don't know what libraries get included and if it will work on another computer. GNU tools are text-driven, so easier to replicate and to reason about.
We did not do bare bones C already in those days.
https://visualstudio.microsoft.com/downloads/#build-tools-fo...
But you are swimming upstream if you use the GNU tools for general Windows development. Windows is a complex, integrated system that has evolved over a long period of time and is very different from unix-like operating systems. The peculiarities that exist in MSVC and associated tools are not just the whimsies of Microsoft devdiv engineers and product managers, but often tie in to operating system functionality. If you try to develop Windows applications with mingw, you will eventually hit weird problems and errors that simply would not exist if you used Microsoft's toolchain.
If you want an alternative to Microsoft's compiler, then consider llvm, which is aiming for full ABI compatibility and even produces PDBs (though I'm skeptical that they're as complete as the ones generated by Microsoft's tools). But the compatibility is incomplete, so ymmv.
Microsoft seems to aim for deep integration of Linux in Windows per WSL. They even showcased that they are working on Wayland support for WSL, which would enable using Linux GUI applications directly on Windows.
We may soon get at a point where Linux applications feel as native on Windows as native Windows applications (which use quite a variety of toolkits anyway), as the integration deepens.
Now WSL still uses larger distribution images. But very little holds them from supporting thin Linux images with just the necessary dependencies that launches in Windows as any other application.
Using LLVM for ABI compat is a good tip though!
I don't know if it will ever come with a vanilla Windows Home edition install but somehow I doubt that.
I don't see what they have to lose. Windows is still used widely in business. But their lock-in has drastically reduced with the rise of iOS, Android, and web apps. Making Windows more attractive as a platform for developers to deploy applications, even if it is through the WSL subsystem will make Windows as a platform more competitive to these other ecosystems.
I am currently writing scientific software. But we have stopped building Windows versions, since these programs work great with WSL and it is far less effort than building these applications separately with Visual C++.
I'm currently in a weird spot with the software I distribute because the majority of the users "know enough to be dangerous" but aren't software engineers/IT professionals. We want them running code and using Linux like a pro, but there's a lot of training/documentation overhead just for our *nix builds and the friction to getting that up and running for WSL is daunting.
Luckily MS understands B2B native more than anyone else so I'm hopeful they'll have a solution eventually, but I'm not holding my breath until then.
I am not sure what the difference is, when WSL gets deeper and deeper integration with Windows. WSL2 does not use the personality mechanism anymore, but that's just to make it easier to fully support Linux. But once Linux becomes a personality of Windows in the informal sense, targeting Linux means targeting Windows at the same time.
But not as miserable as trying to use gnu tools for building C++ on windows. I have over a decade of exprience in that and it's always equally painfull.
There were good reasons to use GNU tools when MSVC did not have thorough enough support for C++11 and GCC did. Now MSVC is pretty good with the latest C++ standard.
Besides, Windows now comes with a real posix virtualized environment - Windows subsystem for Linux - which works great - use that, not msys2 or cygwin if you must have a gnu build system on a windows...
The latest version of the VS2019 installer already packages clang 10.
If it is true, it would be amazing. So many of my APIs are unwieldy because of Microsoft's refusal to support this one feature.
Read the comments, it should be available in the next VS2019 update.
Using such tools for me was only to do university work at home.
It tries to embrace it, but this is not necessary (and limited for non-trivial cases - and what isn't non-trivial for serious projects). CMake itself has good VS support for a long time. I always try to create VS solutions in parallel with ninja, nmake, jom, whatever completely from it without hand-holding of some integration.