Regenerate translation data when TRANSLATION changes in a build dir - #11372
Regenerate translation data when TRANSLATION changes in a build dir#11372dhalbert wants to merge 1 commit into
Conversation
`compressed_translations.generated.h` depended only on the generator, the `.mo` file and `qstrdefs.generated.h`, all of which are older than the header once a language has been built once. Building another language in the same directory therefore kept the previous language's Huffman tables and linked the new language's strings against them, and switching back to an already-built language did not relink at all. Add `translation.stamp`, rewritten only when `TRANSLATION` differs from its content, as a prerequisite of the header. A language change now regenerates the header and `translations-*.c`, which rebuilds `translate.o` and the translations object and relinks the firmware. Rebuilding the same language is still a no-op. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Tested on our 8 board farm: Metro M0 Express, Metro M4 AirLift Lite, Metro RP2040, Metro RP2350, Feather nRF52840 Express, Feather STM32F405 Express, Metro ESP32-S2, Metro ESP32-S3. Built en_US, fr, en_US, en_US in one build directory per board. With the patch the header and firmware checksums changed on each language switch and came back to the step 1 values, the fourth build was a no-op, and the step 3 firmware matched a clean en_US build. The same sequence on the merge base (M4) reproduced the bug: step 3 finished in 1 s and left the fr firmware in place. Then flashed the fr build and the step 3 en_US build on each board and checked the REPL (ImportError text and the soft reboot line). All 8 boards printed French, then English. Image sizes are unchanged vs the merge base. Bytes free in flash, en_US:
Looks good to us. |
|
The meowbit failure is not due to the changes here. |
2 participants
Claude wrote this fix, with @dhalbert directing and reviewing.
Problem
Building a language for the second time in the same build directory produces broken firmware. For example: build en_US, then fr, then en_US again.
compressed_translations.generated.hdepends on the generator script, the language's.mofile andqstrdefs.generated.h. On the third build all three are older than the header that fr just generated, so make does not regenerate it.translations-en_US.cis a side effect of the same rule, so it is not regenerated either. The firmware links en_US strings against fr's Huffman tables and prints garbage. Its size looks plausible, so nothing flags the problem.First visits are fine: the
.mofile is created fresh, so the header regenerates. That is why the release builds, which visit each language once, are unaffected.Fix
py/py.mk: add$(HEADER_BUILD)/translation.stamp, aFORCErule that rewrites the file only when its content differs from$(TRANSLATION), and make it a prerequisite ofcompressed_translations.generated.h. A language change regenerates the header andtranslations-*.c, which rebuildstranslate.oand the translations object and relinks. Rebuilding the same language stays a no-op.Testing
Built metro_m4_express en_US, fr, en_US, en_US in one build directory: the header's checksum changed on each language switch and returned to its original value, the firmware relinked each time with the correct size (4,952 bytes free for en_US, 1,596 for fr), and the fourth build regenerated and relinked nothing.
🤖 Generated with Claude Code