Skip to content

__revision__ goes stale in a reused build dir, and never names the release tag #156

Description

@bdbarnett

Two things about the revision string the C modules report (audioecho.__revision__ and friends), both seen on 2026-09-27 building the ESP32-P4 image on v0.6.2.

It's stamped when CMake configures, not when it builds. An incremental rebuild in a reused build directory, after the audiodsp checkout moved from a branch to the v0.6.2 tag, flashed the old gc518ba0 string over v0.6.2 code. Deleting CMakeCache.txt fixed it. Any firmware built in a reused build dir after moving the checkout carries a stale revision, and the effects program's board gates read that string as the pin.

It names v0.0.3, not the release. At the v0.6.2 commit it reads v0.0.3-283-g1c89b03: the release tags are lightweight, and git describe without --tags names the last annotated tag. The hash is right; the name isn't what a reader expects.

Suggested fix: compute the revision at build time (a custom command that regenerates the header when HEAD changes), and use git describe --tags in micropython.cmake and micropython.mk (and the CircuitPython path), or have the release chain cut annotated tags. The CPython wheel's _audiodsp.__revision__ should follow the same rule.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    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