Apply and persist required esp-idf changes for esp_config.h files

[chris-subtlebytes]

Motivations

Some files in the ESP IDF require local modifications because they don't have sdkconfig options for them.

In my case, I need to enable MBEDTLS_USE_PSA_CRYPTO, which can only be enabled by patching:
components/mbedtls/port/include/mbedtls/esp_config.h:

#define MBEDTLS_USE_PSA_CRYPTO

There's also some broken sdkconfig option combinations that need some local patching for now and eventually upstream fixes. In my case, some TLS1.2 macros still try to compile when the TLS1.2 config is disabled.

As of now, there's no official way to automate patching or persist these changes reliably. If these patches are committed, then the cargo build system will actually erase the changes with a fresh sync of the esp idf remote. The current workaround is to manually apply them and leave the .embuild/espressif/esp-idf/v* repo dirty.

• Would you like to implement this feature? [y/n]

No

Desired behavior

A user can download an esp-idf-sys based repository that requires patches to esp-idf and upon cargo build, it automatically syncs the esp-idf (as it does today, or by explicit syncs as some other open FRs suggest), then applies the required patches on top so that the build is successful.

Alternatives

Additional context

[ivmarkov]

Sorry for replying with a delay.

I'm are actually trying to escape the notion of "patches", and - since quite some ESP-IDF releases - we don't have to apply patches anymore. The last release which needs patches is V5.0.X (and the no longer officially supported 4.4.X), and that's only if you would like to use the esp_app_desc! macro.

Back in the days, the ESP-IDF build was based on PlatformIO (feature pio which is still around, but no longer the default, and I bet not used by anyone by now).

With PIO, we did not have any meaningful alternative, as the PIO build does not clone an ESP-IDF GIT repo, but rather, downloads the ESP-IDF as ZIP or so.

These days what I would rather suggest is the most natural thing, which is - if you need your custom changes, then just fork the ESP-IDF repo, make your changes in your own fork, and then instruct esp-idf-sys to use your fork rather than the official ESP-IDF GIT repo & branches.

And the above is a necessary setup for PR-ing/upstreaming the changes, so you would need it anyway if you plan to upstream those.