Yep, makes sense, I prefer not to edit the fpc.cfg file, I have been building with a script that offers all that content on a fpc command line, easier IMHO to manage.
Yes, there are many ways to supply information to the compiler, so do whatever fits in best with your workflow.
But I still find myself missing symbols esp_app_get_elf_sha256, esp_partition_main_flash_region_safe, esp_app_get_description
Easy to look them up in the map file you mention and find the .a file they live in. And easy to manually add then to the link file and it all builds. But thats no solution. How can I tell FPC about needing them ? It finds all the other object archives it needs ?
The list of libraries required to link a minimal project depends on the ep-idf version. This is handled by having secondary units with the version dependent list of esp-idf libraries, e.g.
esp32c3idf_50000.pp. FPC will select the applicable unit based on the esp-idf version specified via -WP.
What are your plans with "packaging" this ? Its a labourous process installing IDF and its associated tool, it appears to me it would be legal to just cherry pick all the needed libraries and put them 'somewhere' suitable but how about the assembler and linker ? Oh, and that esptool.py thing ....
Michael Ring is
working on a script that does exactly this, packaging the esp-idf libraries, fragments, python tools, bintools and a python environment. This is used with fpcupdeluxe at the moment, so the end user just selects the target in fpcupdeluxe, then all the required files are just copied across. Of course fpcupdeluxe only support esp8266 (v3.4) and esp32 (v4.3) at the moment, but this will change as the situation stabilizes.
And should that process be based on the 5.2.1 stable release ?
I'm working with esp-idf
v5.0.6 at the moment, since it appeared to correspond with what was in FPC when I started. Once I get the platform working, it is relatively easy to cover other esp-idf versions.
Edit: Added link to Michael's post of espsdk4fpc
Recent
