esp-idf-sys

esp-idf-sys copied to clipboard

Currently, they are tucked away in the build folder of esp-idf-sys, in which a unique fingerprint is appended to the folder name. E.g

target/xtensa-esp32-espidf/debug/build/esp-idf-sys-1d1212f75c9bfd7a/out/build/bootloader/bootloader.bin

Because of the fingerprint, it's not possible for tooling (like espflash) to grab the bootloader and partition table automatically. If we moved it to a known location in the target directory we could allow tooling to automatically pick up bootload and partition table changes.

I think moving them to the $TARGET/$PROFILE/ makes sense. E.g target/xtensa-esp32-espidf/debug/build/esp-idf-sys-1d1212f75c9bfd7a/out/build/bootloader/bootloader.bin would get copied to target/xtensa-esp32-espidf/debug/bootloader.bin.

You can actually build the crate with cargo build --message-format json and extract these messages with the cargo_metadata crate (using cargo_metadata::MessageIter). One such message is BuildScript which contains the path to the our-dir of that build script.

I actually use that approach in my (very long) WIP cargo-idf tool here. You can get almost all information with that and cargo metadata.

That's a good point! Definitely useful for the cases where the tool is invoking the cargo build process. In the case of espflash (note, not cargo-espflash, the wrapper) it is typically used as a cargo runner, and has no sway over cargo's build process.

Hypothetical usage I am picturing.

[target.xtensa-esp32s2-espidf]
runner = "espflash --bootloader target/bootloader.bin --monitor"

I suppose it be possible to write a build script that could find the esp-idf-sys directory inside target/ and move it to where ever?

@MabezDev I have followed the advice of @N3xed and used the messages provided by cargo_metadata to locate bootloader.bin/partition-table.bin and use them whenever able in cargo-espflash. Once I have tested this more I will open a PR.