[bdbarnett]

build_mp.py now builds OmniPython (CircuitPython-compatible) firmware too: CircuitPython with our C modules compiled in through its own USER_C_MODULES, for CircuitPython's ports and boards.

./build_mp.py --interpreter circuitpython --port raspberrypi --board adafruit_feather_rp2040 --modules pygraphics
./build_mp.py --interpreter circuitpython --port atmel-samd --board sparkfun_samd51_thing_plus --modules pygraphics
./build_mp.py --interpreter circuitpython --port unix --modules pygraphics

It's a flag rather than a second command because the module names and modules.lock, the workspace links, the output layout and the build record are shared; what differs is one function. The build plan's new section, "CircuitPython-compatible builds", has the details:

• The pin. deps.lock pins CircuitPython at 11.0.0-alpha.1 (520805e12), whose core is MicroPython 1.29, so its py/py.mk carries the same USER_C_MODULES block as our MicroPython builds and a module's micropython.mk works unchanged. It's cloned into deps/circuitpython, never linked to a sibling checkout, and each build fetches only the submodules its target needs with CircuitPython's tools/ci_fetch_deps.py. Its build tools go in deps/circuitpython-venv, from its requirements-dev.txt.
• Modules. --modules works as for MicroPython. CircuitPython freezes Python its own way, so a module with no micropython.mk is refused for now rather than left out.
• Two traps. mpy-cross is built first, on its own (the BUILD= sub-make trap). make gets a short BUILD=build-<board> link to our build dir, because raspberrypi's link step echoes every object path in one shell argument, and with a long absolute path in front of each that passed Linux's 128 KB limit.
• Output in builds/circuitpython/<port>/<board or variant>/, with the same build record. The record logic is now one function both paths use.
• modules.lock: pygraphics at b98288c, which builds as a user C module in CircuitPython (Build as a user C module in CircuitPython too pygraphics#41). That also brings pygraphics#36 and README and newcomer guide: the installer clones into the current directory #38.
• A CI workflow builds CircuitPython's unix port with pygraphics from a bare clone and checks that it draws.

What was run:

• CircuitPython unix (coverage) with pygraphics: imports, draws, reads the pixels back, implementation() is native_cmod. A stock build of the same target fails that check.
• adafruit_feather_rp2040: UF2 built, MODULE_DEF_PYGRAPHICS in the module table, mp_module_pygraphics in the ELF; firmware 886,968 B of 1,020 KB (84.9 %), 51,400 B more than stock.
• sparkfun_samd51_thing_plus: the same; 578,332 B of the 1,000 KB firmware region (56.5 %), 41,476 B more than stock.
• MicroPython unix with the same pygraphics, through this branch's build_mp.py: draws and reads back as before.

Not yet: running either board image on hardware.

The banner is CircuitPython's own, e.g. Adafruit CircuitPython 11.0.0-alpha.1 on 2026-10-08; Adafruit Feather RP2040 with rp2040; the build changes no version string or board name.