Compared to CMake
The goal is coverage of the workflows people actually use, rather than one-for-one syntax compatibility.
| CMake | Zaza |
|---|---|
CMakeLists.txt | build.zig |
add_executable() | CppExample.executable(...) |
add_library(STATIC ...) | CppExample.staticLibrary(...) |
add_library(SHARED ...) | CppExample.sharedLibrary(...) |
target_include_directories(PUBLIC ...) | .public_include_dirs |
target_compile_definitions(PRIVATE ...) | .private_defines |
add_custom_command() | .custom_commands + .generated_source_files |
install() / export() | .install_headers, .export_cmake, .export_name |
find_package() | package manifest read at configure time |
FetchContent | registry entry resolved into build.zig.zon |
CMakePresets.json | ZAZA_PRESET |
| toolchain file | a target triple |
CMAKE_PARITY.md is the honest version: a tiered feature
plan with a status column marking each concept as partial, missing, or done, and
an explicit list of what to avoid building before the core target model is
solid. Read it before betting a project on Zaza.
The short summary of that document: executable and library targets, install and
export, dependency fetching, custom commands, and CMake interop all work today
and have examples. Transitive usage requirements, object and interface
libraries, find_package-grade discovery, and add_subdirectory composition
are partial or missing.