Code size report:

Reference:  examples/natmod/re: Fix building with Clang toolchains. [1454c3e]
Comparison: unix: Migrate coverage variant to use c_module() in manifest. [merge of 45cf384]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

This is an aggressively sensible change, and as much as I'm bought into the spaghetti of CMake tooling I've built to handle C modules... doing it this way makes so, so much more sense. 👍

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (1454c3e) to head (45cf384).

@@            Coverage Diff             @@
##           master   #18229      +/-   ##
==========================================
- Coverage   98.51%   98.51%   -0.01%     
==========================================
  Files         177      180       +3     
  Lines       22927    22982      +55     
  Branches        0        5       +5     
==========================================
+ Hits        22586    22640      +54     
  Misses        341      341              
- Partials        0        1       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Note on subpackage example fix: Found what appears to be a bug in examples/usercmodule/subpackage/micropython.cmake - it references examplemodule.c but the actual file is modexamplepackage.c. The Make version (micropython.mk) has the correct filename.

This went unnoticed because:

1. The subpackage cmake file isn't included in the parent examples/usercmodule/micropython.cmake
2. Existing CI builds either use Make (correct filename in .mk) or use the parent cmake (which excludes subpackage)
3. Direct inclusion via c_module("path/to/subpackage") is the first time this cmake file actually gets processed

Fixed in commit fdffeeb2f6. Could be a copy-paste error from when the example was added in 2023, though haven't confirmed this with the original author or other maintainers yet.

Did a couple of small cleanups on top of this:

The new manifest processing logic added to py/usermod.cmake has been extracted out into its own py/manifest.cmake, parallel to py/manifest.mk. usermod.cmake just includes it now, so the file that ports reference stays unchanged. It was a bit odd having manifest-processing logic buried inside usermod.cmake with no obvious way to find it.

The py/mkrules.mk include $(TOP)/py/manifest.mk was also redundant - all ports include py.mk before mkrules.mk, and manifest.mk has an include guard (MANIFEST_MK_INCLUDED), so that second include was always a no-op. Removed it.

Quick sanity check on all four affected ports using the manifest_test.py files with c_module() entries - unix/coverage, PYBV11 (stm32), RPI_PICO_W (rp2), and ESP32_GENERIC (espressif idf container) - verified via nm on the ELF / cmake "Found User C Module(s)" output confirming all three modules linked in. On unix the modules also work at runtime: cexample.add_ints(1, 2) returns 3, cppexample.cppfunc(3, 4) returns (7, 'hellocpp'), and example_package is importable.

The new manifest processing logic added to py/usermod.cmake has been extracted out into its own py/manifest.cmake,

The py/mkrules.mk include $(TOP)/py/manifest.mk was also redundant - all ports include py.mk before mkrules.mk, and manifest.mk has an include guard (MANIFEST_MK_INCLUDED), so that second include was always a no-op. Removed it.

I don't see either of these changes in the latest PR here. Maybe it wasn't pushed properly?

Just a note that CI is failing here.

@andrewleech Feel free to request a review when you get a chance to look at this again.