ESP-IDF as submodule in project structuring?
Posted: Fri Nov 14, 2025 5:47 pm
For context, Espressif usually installs the ESP-IDF in a system-wide location, like `C:\Espressif\frameworks\esp-idf-v5.y.z\`, and then projects anywhere can be configured to use it. This also hooks up a bunch of other stuff like ESP-IDF CMD and tells VS-Code where to find the ESP-IDF.
We've had to fork ESP-IDF to fix a few bugs, so we added our own git remote and some tags like ${PRODUCT_NAME}_${PRODUCT_MAJOR}.${PRODUCT_MINOR}.${PRODUCT_MICRO}. This works well enough, but it's annoying because to get a reproducible build we have to ensure the ESP-IDF commit and product commit are synchronized before building a release.
I was considering moving the ESP-IDF sources as a submodule inside the project repository. This would allow the project repository to specific a specific commit, and git would tell us if it wasn't correct. I've done this before with other RTOS platforms, but never something with as much host-OS integration as ESP-IDF. Has anyone tried this? Did you run into any troubles?
Thank you for your thoughts.
We've had to fork ESP-IDF to fix a few bugs, so we added our own git remote and some tags like ${PRODUCT_NAME}_${PRODUCT_MAJOR}.${PRODUCT_MINOR}.${PRODUCT_MICRO}. This works well enough, but it's annoying because to get a reproducible build we have to ensure the ESP-IDF commit and product commit are synchronized before building a release.
I was considering moving the ESP-IDF sources as a submodule inside the project repository. This would allow the project repository to specific a specific commit, and git would tell us if it wasn't correct. I've done this before with other RTOS platforms, but never something with as much host-OS integration as ESP-IDF. Has anyone tried this? Did you run into any troubles?
Thank you for your thoughts.