← index #18200PR #14127
Off-topic · high · value 0.542
QUERY · ISSUE

Why PC .c files full path strings are in built Micropython firmware (usermod) ?

openby garywillopened 2025-10-03updated 2025-10-07
bugport-esp32

Port, board and/or hardware

esp32

MicroPython version

1.26.1

Reproduction

.

Expected behaviour

.

Observed behaviour

I'm upgrading from MPY 1.25 + IDF 5.3 to MPY 1.26.1 + IDF 5.4.2 , for ESP32C3. I built my MPY firmware. Using a lot of custom code in usermod.

Using strings micropython.bin command, I found that newly generated micropython.bin contains many usermod .c file absolute PC path strings:

/onpc/long/path/micropython/ports/esp32/usermod/aa.c
/onpc/long/path/micropython/ports/esp32/usermod/xxxx/gg.c
....

(only usermod .c file paths appeared. Other MPY .c file path not)

Although those PC path strings won't take 200KB, is their being there in firmware is a config bug? (Since MPY 1.26 or since IDF 5.4 ?)

I checked firmware files I built before upgrading (also have usermod). Those path strings were not in old firmwares.

When you have many .c files in usermod, those strings can take tens of KB, which is not good for small-Flash mcu.

Additional Information

I didn't add any debugging or logging flag to build config.

My .cmake in usermod has always be like:

add_library(usermod_xxxx INTERFACE)
target_sources(usermod_xxxx INTERFACE
    ${CMAKE_CURRENT_LIST_DIR}/xxxx.c
    ${CMAKE_CURRENT_LIST_DIR}/xxxxx.c
.....
)
target_include_directories(usermod_xxxx INTERFACE
    ${CMAKE_CURRENT_LIST_DIR}
)
target_link_libraries(usermod INTERFACE usermod_xxxx)

Code of Conduct

Yes, I agree

CANDIDATE · PULL REQUEST

Support board level configurations

closedby gentijoopened 2024-03-19updated 2026-02-24
port-esp32

This PR allows ESP32 board level configuration at both the idf_component.yml file and the USER_C_MODULES.

The idf_component.yml control occurs by looking for a main directory that also incorporates the MICROPY_BOARD variable as part of the name main_{arch} (i.e. main_esp32) , if a folder does not exist then it falls back to previous behaviour.

For the USER_C_MODULES, the usermod.cmake will look in the USER_C_MODULES directory for ${MICROPY_BOARD}_micropython.cmake, if that does not exist then it will look for a micropython.cmake after that it will fall back to the previous behavior to do a directory scan.

This will allow boards to specify which USER_C_MODULES will be incorporated and allow unused modules to exist without adding extra code to the build.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied