improvements to esp32 build configuration

[UncleGrumpy]

To streamline the esp32 build process and simplify deploying custom built images, idf.py build will now create the complete atomvm-${target}.img, including the libraries, if esp32boot.avm is found from a previously run generic_unix build. To help minimize confusion for users, there is also a prominent message with instruction for flashing the complete image.

Theses changes also expose cmake build options in the idf.py menuconfig utility.

These changes are made under both the "Apache 2.0" and the "GNU Lesser General Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[petermm]

Not sure I like this bundling of commands:

1. Imho it's a coupling, implicit behaviour change - which might hinder future things, like point 2..

2. In a simulator flow I use: idf.py build && touch ~/path_to_project/atomvm_wokwi_bins/flasher_args.json (as to build and then reboot sim) - and having mkimage in there would slow things down.

But I'm also a poweruser of idf.py build && ./build/mkimage.sh - so I get the drift, but not sure I understand how it simplifies deploying custom images..

[UncleGrumpy]

@petermm, I don’t want to disrupt anyone’s workflows. My goal was just to streamline the process for newer users who need to build a custom image to include additional components, like atomvm_mqtt. It makes more sense for me to add an additional cmake job called “deploy” (or similar) that will build the complete image and flash it to the target device using the generated ./build/flasjimage.sh script, leaving the default “build” task unchanged, this will better my goal and should have no affect on any pre-existing workflows.

[pguyot]

Should we keep a way to not create the image? (it's not much longer anyway). When working on the VM, I usually only reflash with idf.py flash which is faster than flashing the whole image.

Also, one of my workflows (la machine, obviously) does not include esp32boot.avm at all because it seems to me that esp32boot.avm doesn't bring anything to production images. I'll definitely work around this improvement for newcomers, though.

Likewise, qemu-based tests only use artifacts created by idf.py build (the VM, the partition map and the bootloader) and not the full image.

[UncleGrumpy]

Should we keep a way to not create the image?

I converted this back to draft, because I realize after @petermm’s comments that could be intrusive on existing workflows, so instead I will create and document a new build task that can be used as an alternative to idf.py build that will create the ready to deploy image, or even flash the image after building so that flashing a new custom image can be achieved with one command.

[pguyot]

Should we keep a way to not create the image?

I converted this back to draft, because I realize after @petermm’s comments that could be intrusive on existing workflows, so instead I will create and document a new build task that can be used as an alternative to idf.py build that will create the ready to deploy image, or even flash the image after building so that flashing a new custom image can be achieved with one command.

This sounds like a better approach indeed and would be very welcome. I also find it frustrating to have to call the bash script to build the image when I need it.