Closed MabezDev closed 6 months ago
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.
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.gtarget/xtensa-esp32-espidf/debug/build/esp-idf-sys-1d1212f75c9bfd7a/out/build/bootloader/bootloader.bin
would get copied totarget/xtensa-esp32-espidf/debug/bootloader.bin
.