Zaza

Source: github.com/godofecht/zaza

What Zaza is

Starting a new native project usually means writing CMake. That buys you a second language, a second mental model, and a configure step that has to be debugged separately from the code. Cross-compilation and mixed-language work sit on top of that as further layers.

Zig already ships a build system with a dependency graph, content-addressed caching, a C and C++ compiler, and cross-compilation to every target it supports. What it does not ship is the higher-level vocabulary that C++ projects expect: usage requirements, install and export rules, package manifests, generated-source pipelines, preset profiles, and a path for depending on libraries that only build with CMake.

Zaza is that layer. A build.zig declares targets in Zig, and Zaza turns them into std.Build steps.

const std = @import("std");
const cpp = @import("build_lib/cpp_example.zig");

pub fn build(b: *std.Build) !void {
    const exe = try cpp.CppExample.executable(.{
        .name = "my_app",
        .source_files = &.{"src/main.cpp"},
        .public_include_dirs = &.{"include"},
        .public_defines = &.{"MY_APP=1"},
        .cpp_std = "17",
    }).build(b);

    const run_cmd = b.addRunArtifact(exe);
    const run_step = b.step("run", "Run my_app");
    run_step.dependOn(&run_cmd.step);
}

What this gets you

• C, C++, Zig, and Rust targets in one graph, linked to each other.
• Cross-compilation with a target triple and no toolchain file.
• CMake-only dependencies cloned, configured, built, and installed by the graph.
• Install and export output that a separate downstream project can consume.
• WebAssembly targets, both WASI and freestanding, in the same build file.

What it does not get you

Zaza is example-driven and its public API is not settled. The higher-level target model is still CppExample rather than a first-class library type. See ROADMAP.md for what is being built next.