Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement esp_idf_min_version_MAJOR_MINOR_PATCH cfgs for all released ESP IDFs so far #341

Open
ivmarkov opened this issue Sep 18, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 18, 2024

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}");
    }
}
@ivmarkov ivmarkov added the enhancement New feature or request label Sep 18, 2024
@Vollbrecht
Copy link
Collaborator

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

2 participants