Hacker News Reader

Comment by PaulDavisThe1st | Hacker News Reader

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

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"?)

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>

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

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.

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

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

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.

Reply on news.ycombinator.com