Copy bootloader and partition table to target folder

[thetek42]

After the build completes, the bootloader.bin and partition-table.bin files will be copied to the target folder, next to the build binaries. This allows tools such as espflash to use the bootloader and partition table more easily (see #97).

For example, this will copy target/xtensa-esp32-espidf/release/build/esp-idf-sys-66049b51093b6161/out/build/bootloader/bootloader.bin to just target/xtensa-esp32-espidf/release/bootloader.bin.

Closes #97

[ivmarkov]

Have you checked that this is actually necessary - at all - with recent cargo espflash?
Just the other day in the Matrix chat a user shared that it just works out of the box, as long as you are using cargo espflash.

@jessebraham Can you shed some light here?

[thetek42]

Correct, it should work out of the box with cargo espflash. However, the project we are developing uses regular espflash, which does not work like that. Copying the files to a more accessible location would also make things such as signing the bootloader for use with secure boot easier.

[Vollbrecht]

They maybe plan to merge cargo espflash and espflash. So i would hold any attempts to change default behavior that are potentially breaking only to have them undone because the default behavior of espflash changed again in the light of that planned change.

So if we have concluded esp-rs/espflash#505 i am ok going forward here.

[ivmarkov]

It won't change the default behavior in that the bootloader and the partition table would only be copied to another location...

On the other hand, this way we would be violating a bit the "cargo rules" that actually prohibit us from writing anywhere outside the passed "OUT" build script directory.

Not that we are not doing it already, with the .embuild crate-level directory.

I think I'm actually OK with that proposal. Especially if the current magic in the form of cargo espflash is set to disappear.

[ivmarkov]

@thetek42 why don't you guys open a PR for this? Would save some time and you'll wait less...

[Vollbrecht]

about the prohibit rule here - there is an unstable nightly feature that i am personally using that is really practical ... its exactly doing that, coping build artifacts into a dir of your choosing so you dont need to go 3 layers down to get to your elf. The option is called out-dir

[ivmarkov]

about the prohibit rule here - there is an unstable nightly feature that i am personally using that is really practical ... its exactly doing that, coping build artifacts into a dir of your choosing so you dont need to go 3 layers down to get to your elf. The option is called out-dir

I'm not sure that's helpful. The bootloader and the partition table are much further down and inside the target directory, NOT where the elf final binary is.

In fact, the request is to put them where the target elf is. Out-dir foes something different: it moves the elf binaries even outside the target triple - where the user had chosen - which is not what is being asked here.

[thetek42]

I guess one thing we could do for the time being is to put this behind a feature flag. That way, we won't violate any Cargo rules by default, but users who need this feature can still use it.

I might still look into the espflash / cargo-espflash merger in order to see if something could be done on that side.

[ivmarkov]

Overall looks quite OK.

See only my comment for the error handling. I'm not nit-picking - I mentioned this in the previous review feedback as well, but apparently I have not been clear enough in terms of what I meant - sorry!

[ivmarkov]

Well I guess you won't change the signature, won't you? :)
Alright - I will though - post committing your PR. Thanks for it!