| name | sig-regen |
| description | Regenerate C++ and HLSL binding code after editing any .sig file in sources/SIGParser/sigs/. Use this skill whenever you add, edit, or remove a struct, ComputePSO, GraphicsPSO, PassNode, or Pipeline entry in a .sig file, or whenever generated code under sources/HAL/autogen, sources/RenderSystem/FrameGraph/autogen, or workdir/shaders/autogen looks stale or out of sync with the .sig sources. Also use it when a build fails with unknown Slots::, PSOS::, or Passes:: identifiers, since that almost always means the .sig edit was never regenerated. |
Regenerating SIG code
.sig files are the single source of truth for GPU/CPU shared structs, PSO
definitions, and FrameGraph pass declarations. Editing one changes nothing on
its own — the generated C++ and HLSL must be rebuilt from it.
The one thing that goes wrong
generate_sigs.bat does not regenerate code from .sig files. It runs
ANTLR over SIG.g4 to rebuild the parser grammar, which is only needed when
the grammar itself changes. Running it after a .sig edit appears to succeed
and produces no useful change — which is exactly why it's the trap.
The actual generator is bin/debug/sigparser.exe.
Running the generator
The generator resolves every path relative to its working directory —
sigs/ for input, ../../sources/... and ../../workdir/... for output (see
sources/SIGParser/Main.cpp:9-13). Run it anywhere else and it either finds no
input or writes to the wrong place, so the working directory is not incidental:
cd sources/SIGParser && ../../bin/debug/sigparser.exe
If bin/debug/sigparser.exe is missing or older than the .sig edits and the
grammar or generator sources changed, build the sigparser project first —
otherwise you are regenerating with a stale generator and the output won't
reflect template changes.
Deciding whether the project needs regenerating too
Sharpmake enumerates source files at generation time, so the .vcxproj files
list generated sources explicitly. Modifying the contents of an existing
generated file is invisible to the build system, but a new generated file
will not compile until the projects know about it.
After running the generator, check whether the file set changed:
git status --short sources/HAL/autogen sources/RenderSystem/FrameGraph/autogen workdir/shaders/autogen
Lines starting with ?? (untracked) or D (deleted) mean the file set changed
— run generate_project.bat. Only M lines means contents changed in place and
the existing projects already cover it.
Adding a new struct, ComputePSO/GraphicsPSO, or PassNode usually creates
new files, so a new declaration generally does need the project regenerated.
Full sequence
- Edit the
.sig file under sources/SIGParser/sigs/.
cd sources/SIGParser && ../../bin/debug/sigparser.exegit status --short the three autogen directories.- If any file was added or removed, run
generate_project.bat from the repo root.
- Build, and confirm the new
Slots::/PSOS::/Passes:: names resolve.
Reporting back
Say which .sig files changed, what the generator wrote, and — explicitly —
whether generate_project.bat was needed. That last point is what the next
person (or the next session) needs in order to trust the result, since a
missing project regeneration produces a confusing "identifier not found" error
far away from its cause.
Never hand-edit files under the autogen directories. They carry a
DO-NOT-EDIT banner and the next generator run silently discards the changes.
If generated output is wrong, fix the .sig file or the Jinja template in
sources/SIGParser/templates/.
