Implement esp_idf_min_version_MAJOR_MINOR_PATCH cfgs for all released ESP IDFs so far

[ivmarkov]

E.g. #[cfg(esp_idf_min_version_5_1_2)] would be true iff the current ESP IDF version is >= 5.1.2

Reason: this

How to implement? In the esp-idf-sys build script, we can just hard-code an array with all released versions since 4.4.0 (or whatever start), and then use it to generate the cfgs:

/// They will not be that many, and over time when we drop support for older versions, we'll remove from the list
/// As new versions arrive and we do need to reason about these, we'll add to the list
const VERSIONS: &[(u8, u8, u8)] = &[(u8, u8, u8)] {
    (4, 4, 0), (4, 4, 1), (4, 4, 2), (4, 4, 3), (4, 4, 4), (4, 4, 5), (4, 4, 6), (4, 4, 7),
    (5, 0, 0), (5, 0, 1), ...
    (5, 1, 0), (5, 1, 1), ...
    (5, 2, 0), (5, 2, 1), ...
    (5, 3, 0), ...
};

for (maj, min, patch) in VERSIONS {
    if esp_idf_version_major > maj 
        || esp_idf_version_major == maj && esp_idf_version_min > min 
        || esp_idf_version_major == maj && esp_idf_version_min == min  && esp_idf_version_patch >= patch
    {
        // print the cfg
        println!("cargo::rustc-cfg=esp_idf_min_version_{maj}_{min}_{patch}");
    }
}

[Vollbrecht]

Yeah the current cfg's situation gets out of hand on certain parts. Creating separate features for a concrete boundary sounds like a good idea.

Though we might get into problems, when stuff is back-ported. For example 5.0.2 and 5.1.1 would not be compatible e.g our minimal version for a thing would be 5.1.2, but they introduced a 5.0.3 that is also compatible. That kinda logic would still explode.

Though for this special cases we could still use the current pattern as a backup and replace it for every other place where possible.

[ivmarkov]

Yeah the current cfg's situation gets out of hand on certain parts. Creating separate features for a concrete boundary sounds like a good idea.

Though we might get into problems, when stuff is back-ported. For example 5.0.2 and 5.1.1 would not be compatible e.g our minimal version for a thing would be 5.1.2, but they introduced a 5.0.3 that is also compatible. That kinda logic would still explode.

True. :(
I have not yet seen such a case w.r.t. API changes, let's hope these are rare.

Though, if you want to express ver >= 5.0.3 && ver < 5.1.0 || ver >= 5.1.2 you can do:

#[cfg(
    any(
        all(esp_idf_min_version = "5.0.3", not(esp_idf_min_version = "5.1.0")), 
        esp_idf_min_version = "5.1.2",
    )
    ))]

... not that readable anymore, yet still more readable than the massacre we have right now.

Though for this special cases we could still use the current pattern as a backup and replace it for every other place where possible.

Yes, current patterns are not to be retired.