I don’t know if anyone worked on this, but I vaguely remember someone making something similar. From my understanding every build tools (make, build.zig, just etc…) are just a way to build a DAG (Directed Acyclic Graph) Meaning that whatever steps, or things that you need to do, there should always be a starting point, and an ending point. So for example when you have something like this :
pub fn build(b: *std.Build) void {
const target = b.standardTargetOptions(.{});
const optimize = b.standardOptimizeOption(.{});
const lib_mod = b.addModule("zdt", .{
.root_source_file = b.path("src/root.zig"),
.target = target,
.optimize = optimize,
});
const lib = b.addLibrary(.{
.linkage = .static,
.name = "data-structures",
.root_module = lib_mod,
});
b.installArtifact(lib);
const lib_unit_tests = b.addTest(.{
.root_module = lib_mod,
});
const run_lib_unit_tests = b.addRunArtifact(lib_unit_tests);
const test_step = b.step("test", "Run unit tests");
test_step.dependOn(&run_lib_unit_tests.step);
const lib_check = b.addLibrary(.{
.linkage = .static,
.name = "data-structures",
.root_module = lib_mod,
});
const check_step = b.step("check", "zls helper");
check_step.dependOn(&lib_check.step);
}
The way I think about it is that you have the entry point which is the command eg. zig build. This then compiles the build script, to build the DAG, so you start to resolve what build means, here for example, it’s building the static library, that library depends, on static linkage and the module lib_mod, which itself depends on whatever code is in src/root.zig which itself may depends on arbitrary large file strucuture, once that’s resolved the lib_mod also depends on target and optimize which depends on the cli arguments, and the native or specified target.
It’s probably more complex than that but at least that’s how I view it, and I’m pretty confident that’s a good enough approximation.
But if you wanted I think that nothing prevents you from using something like Raylib to visualize the entire build graph.
