151–160 of 406 posts
Earlier quoted context omitted.
Visual Studio does have that functionality, via vsconfig files: https://learn.microsoft.com/en-us/visualstudio/install/impor...
Doesn't look like it's versioned, or installs Visual Studio itself.
are we doomed to only read AI slop from now on? to get a couple paragraphs in and suddenly be hit with the realization that is AI?
it's all so tiresome
Earlier quoted context omitted.
MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.
Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
Perhaps winget is enough? winget install Microsoft.VisualStudio.2022.BuildTools
The Build Tools installer first installs the Visual Studio tool to select the workloads you want as well.
What is the minimal winget command to get everything installed, ready for : cl main.cpp ?
Ps: I mean a winget command which does not ask anything, neither in command line, nor GUI ? Totally unattenfed.
Earlier quoted context omitted.
He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw. Git installs its own Mingw and Msys2 stuff but mostly compiled…
Doesn't it come with `pacman` too?
For big C++ projects, the .vsconfig import/export way of handling Visual Studio components has worked well for the large teams I'm on. Tell someone to import a .vsconfig and the Visual Studio Installer does everything. Only times we've had issues is from forgetting to update it with components/SDK changes.
One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system. In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against. Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very ho…
I suspect the pitfall is how you or the zig compiler is linking. Unless you're involving things which vary by OS like hardware interaction, networking, file systems etc, you should not, with a new Lang in 2026, need to do anything special for cross-platform capabilities.
Install:
- contrary to the blog post, the entirety of Visual Studio, because the IDE and debugger is *really damn good*.
- LLVM-MinGW[1]
cl.exe from VS
clang-cl.exe—you don't need to install this separately in VS; just use the above-mentioned llvm-mingw clang.exe as `clang.exe --driver=cl /winsysroot /vctoolsdir `. Or you can use it in GNU-driver-style mode, and use -Xmicrosoft-windows-sys-root. This causes it to target the Windows ABI and links against the VS SDK/VC tools
`clang.exe` that targets the Itanium ABI and links against the MinGW libraries and LLVM libc++.
People really like overcomplicating their lives.
At the same time, learn the drawbacks of all toolchains and use what is appropriate for your needs. If you want to write Windows drivers, then forget about anything non-MSVC (unless you really want to do things the hard way for the hell of it). link.exe is slow as molasses, but can do incremental linking natively. cl.exe's code gen is (sometimes) slightly worse than Clang's. The MinGW ABI does not understand things like SAL annotations[3], and this breaks very useful libraries like WIL[4] (or libraries built on top of them, like the Azure C++ SDK[5] The MinGW headers sometimes straight up miss newer features that the Windows SDK comes with, like cfapi.h[6].
[1]: https://github.com/mstorsjo/llvm-mingw
[2]: https://learn.microsoft.com/en-gb/visualstudio/ide/reference...
[3]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...
[4]: https://github.com/microsoft/wil
[5]: https://github.com/Azure/azure-sdk-for-cpp
[6]: https://learn.microsoft.com/en-gb/windows/win32/cfapi/build-...
If you are compiling for your native system, yes.
But as soon as you try cross-compiling, you are in for a lot of pain.