You supply the ROM, and the Makefile checks every byte

A ROM hash is the entry ticket, and the ROM is not in the repo

The setup section is two hashes and nothing else: an SHA1 of e2929e10fccc0aa84e5776227e798abc07cedabf and an MD5 of f7c52568a31aadf26e14dc2b6416b2ed. Those identify the exact original ROM the decompilation is measured against, and the repository does not contain it. You place your own copy at the repository root as baserom.us.z64, and having it there is a hard requirement rather than a convenience, because the extract step reads it to pull out assembly and assets. The clone line is deliberately narrow as well, asking for a single branch called main, so a contributor gets the working branch and not the history of experiments alongside it. Dependency installation is a single script, and that script doubles as a diagnostic: it will tell you where to place the ROM if it cannot find one, so the path question is answered before the build starts rather than by a failed extraction.

The init target is not a one-time step

The build instructions read as if they were a one-time setup, and they are not. Extraction is required every time the splat yaml file is modified, and the README names both regional files, smashbrothers.us.yaml and smashbrothers.jp.yaml, or anything inside the symbols folder, which is what splat consumes. The consequence is that a git pull can invalidate your build tree even when nothing you edited changed, and the README's own advice is to run make init every time you pull changes. The alternative form is given for when you want to be explicit about it: make init, or make clean followed by make extract followed by make. Only then does a plain make, or make -j with your core count, produce the build.

Two regions share a Makefile, and the Japanese build is marked WIP

Region selection is a variable, and the Makefile is explicit about what switching it costs. VERSION defaults to us, the baserom path is built from that variable as baserom.$(VERSION).z64, and the build tree is build/$(VERSION), which the comment says exists so US and JP artifacts can coexist on disk rather than overwriting each other. The repository carries matching regional files: two splat yaml files and two report files, us_report.json and jp_report.json. The Japanese branch of the Makefile is where the honesty is. It says the JP build is work in progress because many C-side symbols still need to be mapped, so by default it skips the relocData link dependency entirely, and only when RELOC_DATA=1 does it attempt to include the object file so that side of the pipeline can be tested.

The Makefile reads like it was written after a bad afternoon

Several lines exist to prevent a specific failure rather than to express the build. The most telling carries .DELETE_ON_ERROR with a comment explaining that failed recipes must not leave half-written targets with fresh timestamps, giving fixRelocChain's byte-compare gate failing after objcopy had already written the extract as the example, and noting that otherwise the next run treats the poisoned file as current. Build flags are pinned too, with builtin rules disabled and the shell forced to bash with pipefail. Five feature switches default to off, including FULL_DISASM, RELOC_DATA, and NON_MATCHING, and turning on PERMUTER sets SKIP_DEPS to disable dependency generation for the permuter. That is a build file written by someone who has watched a stale artefact survive a failure.

Three scripts, and one of them rebuilds while you type

The debugging section is a three-row table, and the tools divide by what stage of the work you are at. first_diff.py answers the question of where you are: it finds the location and cause of most diffs from the baserom, so it is the first thing to run after a mismatched function. livediff.sh is the inner loop, run with the function you intend to work on, and it sets up a live diffing session where every change you save automatically rebuilds and updates the session, which removes the build-from-scratch step between attempts. mips_to_c.sh handles the starting point, taking a file and a function and generating the required context plus a file in an m2cfiles folder with the m2c output to begin matching against. Two more diff utilities, diff.py and diff_settings.py, sit at the repository root.

macOS needs two macports packages, and Windows is refused outright

Platform handling is short and honest. A macOS section points at two macports packages, MIPS binutils and GNU make, which covers the two things a Mac will not have by default for a MIPS cross-build. Windows is handled differently: the Makefile tests for an OS variable equal to Windows_NT and stops with an error saying native Windows is currently unsupported, so there is no partial path to chase. Elsewhere the build inspects the host rather than assuming it, taking the operating system name from uname -s and probing for the cross linker with a command lookup for mips-linux-gnu-ld. That combination, refuse Windows outright and probe elsewhere quietly, is a reasonable way to spend maintenance effort on the platforms contributors actually use.

Discovery notes at the root, and a tag that names a commit

The repository root carries the findings, not just the build. There are three discovery documents for audio and sound effects, for the particle bank, and for relocation data, plus a separate audio.md, alongside a decomp.yaml, a permuter_settings.toml, and the symbols/, include/, src/, tools/, and docs/ directories. A .clang-format is committed, and so is a CLAUDE.md, which tells you the project expects both a fixed C style and machine-readable instructions in the tree. Release tagging stopped long ago. The single tag is sll_r0_r0_0x0, named as a copy of the old ssb-decomp repository with a commit ID, and it dates from August 4, 2023, while the last push to main is September 8, 2026. The two badges at the top of the README also point at the same decomp.dev URL twice. Alongside the discovery documents sit two report files, us_report.json and jp_report.json, which are per-region status records rather than build output, and a docs/ directory that the README never links to.

Editorial conclusion

This project suits someone who wants to read the assembly behind a Nintendo 64 fighting game in C and is prepared to treat a byte diff as the unit of progress. It does not suit you if you have no copy of the original game, since the baserom is required for extraction and for every diff check afterwards. Before starting, put the ROM at the documented path, confirm the hash matches, and expect to rerun the init target after every pull rather than only when the build breaks.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes