Zig breaking change – Initial Writergate

I don't mind breaking changes if I can fix them within a day.

What bothers me with C/C++ is how difficult it is to cross compile a simple Windows + SDL app from inside WSL without MSVC installed.

I've spent weeks on this.

If Zig saves me from that nightmare, and still lets me use C++ libraries, I will gladly switch over to it.

You'll have to write C API wrappers around your C++ libraries to access them from Zig, but other then that I can cross-compile my mixed C/C++/Zig projects using Windows APIs like DXGI/D3D/WASAPI with `zig build -Dtarget=x86_64-windows` from a Mac with the vanilla Zig toolchain.

...you don't even need to port anything in your C/C++ project to Zig, just integrate `zig cc` as C/C++ compiler into your existing build system, or port your build system files to build.zig.

That works out great, since all the libraries I need are C or have C wrappers anyway. I might actually do this, thanks.

Wait what. Shouldn’t zig crosscompile C++ just fine?

Yes, the C++ code compiles just fine, but to call into C++ APIs from Zig you'll need a C API wrapper (and the same is true for ObjC APIs). Not an issue of course for pure C++ projects when the Zig toolchain is just used for cross-compiling.

None of which has anything to do with C++ the language.

In theory yes, in practice that's irrelevant unless you can show someone has done it, and nobody has in 40+ years as far as I know

That doesn't matter much when it's specifically the C/C++ compiler vendors who don't care about fixing the cross-compilation problem. It would be trivial for C/C++ compiler vendors to make cross-compilation as simple as with the Zig toolchain, but they don't care about the topic and that's why it doesn't happen.

Fast forward a few decades to today and the best solution to cross-compile C/C++ projects is the Zig toolchain (and isn't that kinda weird? A "foreign" toolchain coming along fixing one of the biggest problems in the C/C++ ecosystem just like that as a "side quest"?)

WSL hasn't existed for that long. So I am not sure what "it" is ...

The problem with cross-compiling for Windows or macOS as targets are the runtimes (sometimes required during compilation or building), not the cross-compiling. This also has nothing to do with C/C++ as a language.

We build for Linux and Windows on Linux using gcc/mingw and don't have any fundamental issues doing so. On macOS we need the headers & libraries for macOS, we have to do those inside a VM.

I'd be extremely surprised if you can cross-compile Zig for macOS on a non-macOS platform, unless it doesn't use any macOS native frameworks at any level.

\<rant>

From all that I've experienced in the past few weeks dealing with C projects and various build systems and operating systems, I suspect that using Zig would work perfectly as an easy cross-platform alternative to CMake. Until I open up my code in VS Code and the C/C++ plugin just doesn't work, no auto-completion, no go-to-definition, syntax highlighting is broken, etc., and all because it can't find the files in places it ordinarily expects them to be. And maybe there will be some hacky way to fix it with a setting for the VS Code plugin, but likely not.

I'm not saying this is the case, but literally none of the setups I tried feels non-hacky so far, and every one of them has at least one noticable problem during development. I truly miss the days of writing apps for a single platform using its own native build tools. Maybe that's what I'll do: write this as a native Windows app using Visual Studio (ugh, such an awful editor though) and then if I get sales, port it to Mac OS X 10 using Xcode.app, and compile it for Linux inside WSL with GCC 15.

\</rant>

Sadly, the C++ language does not exist in a vacuum.

In fact, it exists in a world which contains "an ecosystem", tooling, opinionated build systems, various incompatible compilers, and mountains of legacy baggage, and all of these influence the daily experience of programmers using the language.

Pretty sure that Visual Studio is not a crossplatform toolkit. Why would you start there?

Oooh yeah that makes sense.

Maybe I worded it wrong. I want to develop my app in VS Code. I have gotten so very used to everything about how VS Code works over the past 10 years, that Visual Studio feels so unintuitive and backwards and weird. But VS is the king of C development on Windows apparently. That said, I've made some progress getting VS Code to work with the official Microsoft plugins for both C/C++ and CMake, both inside WSL and outside of it, though nothing that doesn't feel somewhat hacky.

I have been doing cross compiling stuff since the Symbian glorious days.

Some people really love to make their life harder, as in your example, targeting Windows from inside WSL, instead Windows proper.