Allow specifying extra compiler flags (warning flags, preprocessor
definitions, etc.) via a new 'compile_options' entry in the
idf-build-file frontmatter. The options are applied to the source
file via target_compile_options in the generated main component
CMakeLists, with CMake quoting so that flags like -DMSG="hello world"
reach the compiler exactly as written.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add a new idf.py extension that allows building standalone C files
without requiring full project boilerplate. Source files can include
optional YAML frontmatter in block comments to specify sdkconfig
options, component dependencies, and target configuration.
When the frontmatter configuration changes, the stale sdkconfig is
removed so the new defaults are applied, and a target change also
clears the build directory since IDF_TARGET is pinned in the CMake
cache.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Restore the use_secure_element field in esp_tls_cfg_t, esp_tls_cfg_server_t
and httpd_ssl_config_t, and esp_transport_ssl_use_secure_element(), as
deprecated no-ops so that existing code keeps compiling. Setting them now
fails at runtime with ESP_ERR_NOT_SUPPORTED, as the feature is accessed
via the esp_key_config_t interface. To be removed in the next major release.
Gate these notes on SOC_SECURE_BOOT_V2_ECC in addition to the ECDSA
peripheral P-384 capability, so they are not rendered for targets
without the ECDSA Secure Boot scheme.
Document CONFIG_COMPILER_LTO_LINKTIME / CONFIG_COMPILER_LTO_COMPILETIME in the
binary size reduction guide, including the caveats: less accurate per-component
size breakdown, longer build times, incompatibility with custom linker
fragments, and harder debugging.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Correct "802.154" to "802.15.4" and change the EUI-64 derivation notation
from base_mac[0:3]/base_mac[3:6] to the inclusive base_mac[0:2]/base_mac[3:5]
in the esp32h2/esp32h21/esp32h4 Kconfig.mac help text and the EN/zh_CN
misc_system_api docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add help text to the esp32h2/esp32h21/esp32h4 Kconfig.mac explaining
that these chips only consume one universally administered MAC address:
the IEEE 802.154 EUI-64 is derived from the base MAC and MAC_EXT, and
Bluetooth reuses the base MAC as-is (no BT offset, since there is no
Wi-Fi).
Add a matching 1-MAC derivation table and note to misc_system_api.rst
(EN and zh_CN) under a new `.. only:: esp32h2 or esp32h21 or esp32h4`
block, and exclude these targets from the generic 4/2 table.
Add an esp32s31-only note stating that the "Four" option may only be
used with a customer-provided custom base MAC range, since ESP32-S31
only provides two universally administered MAC addresses in eFuse.
Co-authored-by: Cursor <cursoragent@cursor.com>
