Daniel Samson
be04ebe954
The module-to-domain table in build-support duplicated what each domain's build.zig already states with its addModule exports. userBinary now resolves each named import by searching the packages the binary declared in its own build.zig.zon (b.available_deps), which also makes the zon the literal include path: an import can only be satisfied by a domain the binary claims, and naming a module whose domain is missing fails the build graph with the domain to declare. build-support is down to the recipe alone. All build variants green; manifest unchanged.
23 lines
892 B
Zig
23 lines
892 B
Zig
//! The acpi service as a binary package (docs/build-packages-plan.md):
|
|
//! this file names the binary and EXACTLY the modules its source imports —
|
|
//! build-support resolves each name from the domains this zon declares.
|
|
//!
|
|
//! The artifact is named "discovery": one swappable process per firmware
|
|
//! fills the ramdisk's neutral `discovery` slot (docs/discovery.md); the
|
|
//! root's -Ddiscovery picks this package or `fdt`.
|
|
|
|
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("acpi.zig"),
|
|
.imports = &.{
|
|
"acpi-ids", "aml", "device-manager-protocol", "driver", "ipc", "logging", "memory",
|
|
"power-protocol", "process", "service", "time",
|
|
},
|
|
});
|
|
b.installArtifact(exe);
|
|
}
|