4 ms·

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 fro

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.

flohofwoe 1y ago
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.
- 90s_dev 1y ago
  That works out great, since all the libraries I need are C or have C wrappers anyway. I might actually do this, thanks.
- forrestthewoods 1y ago
  Wait what. Shouldn’t zig crosscompile C++ just fine?
  - flohofwoe 1y ago
    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.
    - forrestthewoods 1y ago
      Oooh yeah that makes sense.
PaulDavisThe1st 1y ago
None of which has anything to do with C++ the language.
- francasso 1y ago
  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
  - PaulDavisThe1st 1y ago
    WSL hasn't existed for that long. So I am not sure what "it" is ...
- flohofwoe 1y ago
  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"?)
  - PaulDavisThe1st 1y ago
    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.
  - 90s_dev 1y ago
    \<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>
pjmlp 1y ago
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.

flohofwoe 1y ago

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.

90s_dev 1y ago
That works out great, since all the libraries I need are C or have C wrappers anyway. I might actually do this, thanks.
forrestthewoods 1y ago
Wait what. Shouldn’t zig crosscompile C++ just fine?
- flohofwoe 1y ago
  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.
  - forrestthewoods 1y ago
    Oooh yeah that makes sense.

PaulDavisThe1st 1y ago

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

francasso 1y ago
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
- PaulDavisThe1st 1y ago
  WSL hasn't existed for that long. So I am not sure what "it" is ...
flohofwoe 1y ago
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"?)
- PaulDavisThe1st 1y ago
  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.
- 90s_dev 1y ago
  \<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>

pjmlp 1y ago

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.