Problem
Azazel currently models some dependency build options with named special cases such as backend and fields. That was useful for proving real corpus slices, but it does not scale as a generic build-model surface: arbitrary Zig packages can expose arbitrary typed b.option values.
A production build IR should not need a new global schema field every time a dependency invents an option.
Required design
Represent dependency arguments generically as typed values while preserving Zig's compile-time requirement that dependency option field names and enum tags become valid build API expressions.
The model needs at least bool, integer, string, string-list, enum/tag, target, and optimize forwarding, with validation that produces a clear error before std.Build panics.
Existing backend and fields corpus cases should migrate onto the generic representation rather than remain permanent one-off executor branches.
Acceptance criteria
- zgui's backend selection is represented without a hardcoded
backend dispatch table in build.zig.
- uucode's
fields list is represented through the same generic dependency-argument mechanism.
- At least one additional dependency with a different typed option shape is modeled without changing the core schema/executor.
- Invalid option types/names fail during validation or generation with an actionable diagnostic.
- Existing 0.14.1 / 0.15.2 / 0.16.0 CI lanes remain green.
This is distinct from #18: #18 models dependency identity/package metadata; this issue is about the arbitrary typed option surface passed into a dependency's build function.
Problem
Azazel currently models some dependency build options with named special cases such as
backendandfields. That was useful for proving real corpus slices, but it does not scale as a generic build-model surface: arbitrary Zig packages can expose arbitrary typedb.optionvalues.A production build IR should not need a new global schema field every time a dependency invents an option.
Required design
Represent dependency arguments generically as typed values while preserving Zig's compile-time requirement that dependency option field names and enum tags become valid build API expressions.
The model needs at least bool, integer, string, string-list, enum/tag, target, and optimize forwarding, with validation that produces a clear error before
std.Buildpanics.Existing
backendandfieldscorpus cases should migrate onto the generic representation rather than remain permanent one-off executor branches.Acceptance criteria
backenddispatch table inbuild.zig.fieldslist is represented through the same generic dependency-argument mechanism.This is distinct from #18: #18 models dependency identity/package metadata; this issue is about the arbitrary typed option surface passed into a dependency's build function.