[JakeStevens]

Summary

Add examples/espressif/build_idf_component.sh, which generates a
source-vendored, registry-shaped ESP-IDF component from this
repository, following the same approach as the Arduino library
packaging but with an ESP-IDF layout.

The generator produces the schema headers, vendors the runtime and
needed kernel sources (using the same build_variables.bzl lists as
the CMake build), copies the component template from #24292 and the
shared PAL from #24291, and writes et_generated.cmake, Kconfig,
idf_component.yml, licenses, and a VERSION file recording the
ExecuTorch commit and per-profile op-set hashes. Kernel
registration is generated per profile in idf_profiles/<name>.ops;
the component's Kconfig selects which profile compiles, so switching
profiles needs no regeneration. This PR ships one example profile,
wakeword_int8, which mixes portable ATen glue ops with Cadence
backend generic (portable) int8 kernels.

Consumers of the generated component need only ESP-IDF — no host
CMake build and no flatc. Application code and models are not
included; they stay with the application.

Stacked on #24292

Test plan

• Generated the component:
  ./examples/espressif/build_idf_component.sh --profiles wakeword_int8 --out /tmp/et-idf-out
  (component version 1.6.0~3, 80 sources / 292 headers; the
  known exporter/runtime version-skew warning is printed when the
  installed Python package was built from a different commit).
• Verified the generated src/platform/esp_pal.cpp is
  byte-identical to examples/espressif/platform/esp_pal.cpp
  (cmp).
• Built a minimal ESP-IDF consumer that vendors the generated
  component and calls et_model_create, for esp32s3 and
  esp32c5 with ESP-IDF v6.0.1 (idf.py set-target <target> build);
  both complete with Project build complete.
• Ran end to end on Muse Gadget SDK w/ Box 3

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24293

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 19 Pending, 2 Unclassified Failures

As of commit 81bead7 with merge base 822cb60 ():

NEW FAILURE - The following job has failed:

• pull / nxp-mcuxpresso-test / linux-job (gh)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

• Build Aarch64 Linux Native Wheels / executorch-native / build-wheel-py3_11-cpu-aarch64 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  ModuleNotFoundError: No module named 'setuptools'
• Build Aarch64 Linux Native Wheels / executorch-native / upload / upload-wheel-py3_11-cpu-aarch64 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  Unable to download artifact(s): Artifact not found

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[rascani]

Should we add this to CI too?

[rascani]

We should default this to n so we don't bloat users unless they need this.

[JakeStevens]

✅

[rascani]

For the IDF component, WDYT about having it include all ops/delegates we might use, and then use configuration or cmake to select what what actually gets used. I'm concerned we'd start creating N x M profiles for all the model combinations we'd want to support.

[JakeStevens]

Agreed, this is the better long-term shape. Punting to a follow-up PR so this one stays focused.

[JakeStevens]

Should we add this to CI too?

✅ Added the ESP-IDF component (ESP32-S3) job.