Production blocker: generalize typed dependency build options
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- Avg merge
- 8m
- Merged PRs (30d)
- 1
Description
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
backenddispatch table inbuild.zig. - uucode's
fieldslist 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading build.zig and tracing the current dependency-option handling for the zgui backend and uucode fields corpus cases. Define the generic typed representation and validation around those paths, then verify that both cases use it, an additional typed option works without core changes, invalid inputs produce actionable diagnostics, and the 0.14.1, 0.15.2, and 0.16.0 CI lanes remain green.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, zig
- Domain
- build-system, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100