BuildPointers hand-rolls an address-constant emitter LibCodeGen already provides

[thedavidmeister]

script/BuildPointers.sol hand-rolls an address-constant emitter that rain-sol-codegen already publishes.

The duplication

This repo's build script defines its own local emitter for address constant DEPLOYED_ADDRESS = address(...), while LibCodeGen already provides:

// rain.sol.codegen src/lib/LibCodeGen.sol:298
function addressConstantString(Vm vm, string memory comment, string memory name, address data)

The shared version is strictly more general — parameterized over the comment text and the constant name rather than hardcoded to one name.

The script already depends on rain-sol-codegen and already calls LibCodeGen.bytecodeHashConstantString for the codehash constant. So it uses the shared library for one generated constant and a private reimplementation for the other, in the same file.

Scope: four repos, one shared function

Measured 2026-08-13, repos emitting address constant DEPLOYED_ADDRESS from a local helper rather than LibCodeGen:

repo	script
rainlanguage/rain.deploy	script/Build.sol — being fixed in rain.deploy#26
rainlanguage/rain.factory.deploy	script/BuildPointers.sol
rainlanguage/rain.verify	script/BuildPointers.sol
S01-Issuer/st0x.deploy	script/BuildPointers.sol

rain.math.float's build script has no such emitter.

Ask

• Replace the local emitter with LibCodeGen.addressConstantString, passing the current NatSpec as comment and DEPLOYED_ADDRESS as name
• Check whether this repo's local copy has DRIFTED from the shared one in comment text, spacing or line wrapping — a drifted emitter changes generated output, and the generated file is committed, so any difference must be regenerated in the same commit or the git-clean gate catches it
• Report the difference rather than silently changing generated bytes to fit

If LibCodeGen's version genuinely cannot produce the required output, extend rain-sol-codegen rather than keeping a private copy — that is a PR there plus a version bump here.

Why this matters beyond tidiness

The rule is: use the codegen library for codegen, or extend it. Four private copies of one function means four places a generated-output convention can drift apart, in repos whose generated files are frozen deploy pins consumers import.

It is also a symptom of the per-repo build script that rainlanguage/rainix#304 is about — each deploy repo owning its own generator means each one re-solves the same problem privately, and a shared library 300 lines long is easy to miss when a local helper is twenty.