Skip to content

BuildPointers should not exist: pointer generation is part of build #304

Description

@thedavidmeister

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

  • Fold BuildPointers.sol into Build.sol in the four repos carrying the variant
  • Make pointer generation part of the build, so a stale snapshot cannot be committed rather than being caught by a gate
  • Drop pointers-generate-cmd from rainix owns the deploy-repo release freeze: rainix-static cut-release #302cut-release runs the repo's build, and rainix asks for nothing
  • Reconsider the copy-artifacts and git-clean gates once regeneration is not separable: what remains is a determinism check

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).

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions