Daniel Samson
4476208361
Every binary's build.zig now names precisely the modules its source
imports (derived by scanning each artifact's sources, transitively
through same-directory files), and its zon carries only the domains
those come from — kernel stays implicit (the root shim + link script
live there). build-support's userBinary resolves each name through one
module-to-domain table (module_homes); Domains/domains()/defaultImports
and the raw recipe entry point are deleted. An undeclared @import is a
compile error (verified: injecting @import("xkeyboard-config") into
logger fails with 'no module named ... available within module
program'), and e.g. xkeyboard-config now appears in exactly two
manifests — the two keyboard drivers. Availability never bloated the
emitted binaries (Zig compiles only what a program imports); this makes
the declared interfaces honest. Production and -Dtest-case manifests
byte-identical; all build variants and standalone package builds
green.
21 lines
780 B
Zig
21 lines
780 B
Zig
//! The fdt service as a binary package (docs/build-packages-plan.md):
|
|
//! this file names the binary and EXACTLY the modules its source imports —
|
|
//! the shared recipe and the module-to-domain map live in build-support.
|
|
//!
|
|
//! The artifact is named "discovery" like acpi's: the Raspberry Pis hand over
|
|
//! a flattened device tree, and the aarch64 target flips the root's
|
|
//! -Ddiscovery default when it lands (docs/arm.md). A placeholder until the
|
|
//! ARM bring-up.
|
|
|
|
const std = @import("std");
|
|
const build_support = @import("build-support");
|
|
|
|
pub fn build(b: *std.Build) void {
|
|
const exe = build_support.userBinary(b, .{
|
|
.name = "discovery",
|
|
.root_source_file = b.path("fdt.zig"),
|
|
.imports = &.{ "process" },
|
|
});
|
|
b.installArtifact(exe);
|
|
}
|