Why PC .c files full path strings are in built Micropython firmware (usermod) ?
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
Argument list too long compile error [ESP32}
Port, board and/or hardware
ESP32-S3
MicroPython version
1.25.0
Reproduction
compile Micropython for the ESP32-S3 generic and once it is done compiling navigate to ports/esp32/build_ESP32_GENERIC_S3/esp-idf/main/CMakeFiles and edit the qstr.i.last-*.sh script in that folder. CMake builds this file and calls it as part of the build system. What is in this file is the shell command to run makeqstrdefs.py. If you look you will see repeated parameters, ones that start with -I
When compiling MicroPython it will compile fine but if you add a few user_c_modules is when the error happens. The error is because of the added includes from the user c modules.
Expected behaviour
to compile without any errors
Observed behaviour
make[3]: /bin/sh: Argument list too long
make[3]: *** [esp-idf/main/CMakeFiles/BUILD_FROZEN_CONTENT.dir/build.make:799: genhdr/qstr.i.last] Error 127
Additional Information
The fix should be pretty simple. adding list(REMOVE_DUPLICATES MICROPY_CPP_FLAGS) to the py/mkrules.cmake file right above where it says # Generate qstrs in the file.
That will remove all of the duplicate entries.
I do also suggest possibly adding some code that will turn all of the include paths into relative paths instead of absolute ones. It will trim down the length of the arguments as well.
Code of Conduct
Yes, I agree