BuildPointers.sol should not exist as a separate concept. Generating deploy pointers is part of building, not a script you remember to run afterwards.
The org already disagrees with itself
Twelve repos carry a generator script, under two names:
| Name |
Repos |
Build.sol (+ BuildAuthoringMeta.sol, build.sh) |
rain.flare, rain.dia, rain.erc4626.words, raindex, rainlang, rain.merkle, rain.pyth, rain.sol.codegen |
BuildPointers.sol |
rain.factory.deploy, rain.verify, rain.math.float, S01-Issuer/st0x.deploy |
The split tracks the deploy side, so it is a dialect for the same job rather than a different job. Eight repos already call it build.
Pointers are build output
Under CREATE2 the deployed address and codehash are pure functions of the bytecode. They are as derived as the ABI. In the Build.sol repos the build already regenerates several derived artifacts together — raindex's build.sh regenerates ABIs alongside the rest — and pointers belong in that set.
The drift class exists only because regeneration is separable
Every guard around this defends against someone not running the script, or running it in the wrong order:
If building regenerates, a stale snapshot is not gated — it is unrepresentable, and those guards collapse into one determinism check: build twice, get the same bytes.
It decides an input in an open PR
#302 deletes snapshot-generate-cmd and adds pointers-generate-cmd, defaulting to forge script ./script/BuildPointers.sol. If pointers are build output, rainix has no business asking which script produces them — that PR would remove one knob and add another in the same change, and enshrine the minority spelling as the default while doing it.
#302 is held pending this decision, along with its two caller PRs.
Ask
Related: #301, #302, #303 (release-time verify asserts nothing about the snapshot it publishes — generating the tagged assertions alongside the constants is what fixes that too).
BuildPointers.solshould not exist as a separate concept. Generating deploy pointers is part of building, not a script you remember to run afterwards.The org already disagrees with itself
Twelve repos carry a generator script, under two names:
Build.sol(+BuildAuthoringMeta.sol,build.sh)BuildPointers.solThe split tracks the deploy side, so it is a dialect for the same job rather than a different job. Eight repos already call it
build.Pointers are build output
Under CREATE2 the deployed address and codehash are pure functions of the bytecode. They are as derived as the ABI. In the
Build.solrepos the build already regenerates several derived artifacts together — raindex'sbuild.shregenerates ABIs alongside the rest — and pointers belong in that set.The drift class exists only because regeneration is separable
Every guard around this defends against someone not running the script, or running it in the wrong order:
src/generatedagainstscript/Build.solcut-release's regenerate-then-freeze ordering, whose inversion silently publishes one address while permanently recording another (rainix-tag-release delegates cut-release to consumers; the freeze ordering is a silent-corruption hazard #301)If building regenerates, a stale snapshot is not gated — it is unrepresentable, and those guards collapse into one determinism check: build twice, get the same bytes.
It decides an input in an open PR
#302 deletes
snapshot-generate-cmdand addspointers-generate-cmd, defaulting toforge script ./script/BuildPointers.sol. If pointers are build output, rainix has no business asking which script produces them — that PR would remove one knob and add another in the same change, and enshrine the minority spelling as the default while doing it.#302 is held pending this decision, along with its two caller PRs.
Ask
BuildPointers.solintoBuild.solin the four repos carrying the variantpointers-generate-cmdfrom rainix owns the deploy-repo release freeze: rainix-static cut-release #302 —cut-releaseruns the repo's build, and rainix asks for nothingRelated: #301, #302, #303 (release-time verify asserts nothing about the snapshot it publishes — generating the tagged assertions alongside the constants is what fixes that too).