mach VS cc-rs

Did you happen to tinker with https://machengine.org/ it's a Zig game engine & graphics toolkit?

We're working on a game engine in Zig[0]

If you're looking for interesting Zig codebases to read, you might be interested in our low-level audio input/output library[1] or our module system[2] codebase - the latter includes an entity component system and uses Zig's comptime to a great degree to enable some interesting flexibility (dependency injection, global view of the world, etc.) while maintaining a great amount of type safety in an otherwise dynamic system.

[0] https://machengine.org/

[1] https://github.com/hexops/mach/tree/main/src/sysaudio

[2] https://github.com/hexops/mach/tree/main/src/module

Myself and many others are betting on Zig in major ways, I truly think it has a bright future ahead.

In spare time, myself and a few others are working on a game engine in Zig[0], and the Zig core team has been very receptive to addressing issues our project faces and supporting us.

Others are working on pixel art editors[1], open source 2D RPG games[2], there's a group of independent folks working on a 3D massive immersive sim game[3], a group working on making Zig an amazing language for micro-controllers[4], etc.

Please consider donating $5-10 a month to the ZSF! They are a great group of people, and it has so many knock-on effects for others in the FOSS community. :)

[0] https://machengine.org/

[1] https://github.com/foxnne/pixi

[2] https://github.com/foxnne/aftersun

[3] https://github.com/Srekel/tides-of-revival

[4] https://github.com/ZigEmbeddedGroup

I don't know if there's anything better than a zip. For our website[0] which includes a bunch of docs for our game engine, Zig packages, etc. we just offer a link "offline version of this site" in the footer which is an ~80MB zip file.

I think the challenge with zip files is.. do you want all the images? do you want all versions of the docs, or just a specific version of the docs? It's hard to tailor the zip to the user's desire. But zip still seems to be the best.

[0] https://machengine.org/

A game engine https://machengine.org is being written in zig, there's also https://microzig.tech as zig is well suited to embedded development.

https://github.com/hexops/mach (shameless plug)

Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.

WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.

[1] https://github.com/hexops/mach-examples

[2] https://github.com/hexops/mach#supported-zig-version

It does support calling into other compilers and toolchains through build scripts and such. Take cc-rs[0] for example: this allows building C and C++ files natively without even calling an executable yourself.

In practice, I'd expect libraries to just call make/cmake/ninja for you, or (like openssl-sys) ask you to install the necessary libraries using your favourite package manager.

[0]: https://github.com/rust-lang/cc-rs

The cc crate (https://github.com/rust-lang/cc-rs) is widely used for compiling C code from Rust (often in a build.rs file for the purpose of wrapping a C library so that it can be used from Rust). However, I believe it generally does expect a C compiler to be present.

It might be quite tedious to compile static library manually every time we make changes in C code. The better solution is to instead utilize the cc crate, which provides an idiomatic Rust interface to the compiler provided by the host.

https://github.com/alexcrichton/cc-rs This crates lets you shell out to a C compiler when building your Rust project

> You're splitting hairs in a weird way. rustc cannot compile C code. zig can.

But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages.

Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs

rustup and cargo also provide easy cross-compilation support, too.

I think it's getting confused because link.exe is in your PATH. But it's not the link.exe it expects. Link tools are detected using the cc crate so it would need to be fixed there. Would you be willing to open an issue about this?

It’s not super well-documented, but there is an option to change this. --remap-path-prefix $(pwd)= in your RUSTFLAGS will usually do the trick. If you have any C dependencies you’ll also need similar things in CFLAGS, see https://github.com/alexcrichton/cc-rs/issues/593