An observation and suggestions.

It took me a long time to understand how variants worked, and what options there are for configuration as there is little documentation, other than in comments in individual make and header files, and in PR comments such as this, which are hard to find later.
(Or perhaps I just failed to find the docs)

In this case there is a new macro defined, that can be overridden, and that is clearly described here.

I think it would be very helpful to add that to the Documentation, on a common or port level.
That would help tick the 'How can we teach this' checkbox.

@dpgeorge You might also be interested inthis commit, which I'm using for some custom boards that require on-the-fly definitions of partitions.

The advantage of using the IDF API's is that it will (a) do some sanity checks such as throwing an error if new partition you're defining overlaps with any existing partition and (b) adds the partition to the in-memory list of partitions so all other IDF partitions API's recognize it as if it was defined in the partition table.

You might also be interested inthis commit, which I'm using for some custom boards that require on-the-fly definitions of partitions.

Oh, I didn't know aboutesp_partition_register_external()! That looks very useful, thanks. I'll see if I can switch to using that.

I think it would be very helpful to add that to the Documentation, on a common or port level.

@Josverl what exactly are you referring to to add to the documentation? How board variants work, or how this new auto-sizing feature works?

This PR is intended to simplify things so there are less variants and less things the user needs to worry about (ie selecting the right firmware based on the flash size of the board). But I agree it should have a little documentation added. At least on the download page it should say that the firmware works with flash size 4MiB and above.

@dpgeorge , I think that it would be useful to document how the auto-sizing feature works. So that developers can read and understand how it works icw the defied boards and variants.

While I think it's good that fewer variants and boards are needed, this also increases the cognitive effort needed to make use of the existing functionality and (auto) configuration

I've now updated this to be more transparent to the user. It now creates a partition called "vfs" only if there's no such existing partition, and there is either a "factory" or "ota_1" partition. The latter is needed to work out where the filesystem starts.

This works for all boards/partitions: standard, 2MiB, OTA and ROMFS.

I've now added some documentation to the esp32 README, and also updated the relevantboard.md files to account for the changes.

Tested again on a board usingpartitions-4MiB-romfs.csv, it works correctly, the ROMFS is intact and the "vfs" partition starts after ROMFS.