Skip to content

User-facing CMake variables do not update correctly when modified due to caching #2407

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

Open
recursivenomad opened this issue Apr 9, 2025 · 3 comments
Labels
Milestone

Comments

@recursivenomad
Copy link
Contributor

Some user-facing CMake variables (ie. the variables in this table from the SDK guide) have their values cached at various lines in the SDK, meaning that after the initial configuration, any changes to these variables by the user are handled unpredictably, due to adjacent definitions from the prior configuration persisting. It also prevents conditional statements, such as defining a default board intended to be overwritable:

# Due to caching, this will always evaluate to FALSE after first configuration
if (NOT PICO_BOARD)
    set(PICO_BOARD pico2)
endif()

Upon a surface-level search (regex set\(PICO_.*CACHE ), the following variables are affected:

Having the CMake cache is helpful for larger projects; and by having variables be user-facing, that implies (to me) an assumption of mutability. It would be nice if users could reconfigure without needing to delete the build directory or pass --fresh to CMake.

A more detailed description of chaching issues can be see in the related #1618.

I'd be happy to submit a PR to remove the caching for all variables listed above if changing this behaviour into more intentional caching would be something you lot would be open to 👍

@kilograham
Copy link
Contributor

Some of the caching is intentional, and/or needed to force passing variables across otherwise unrelated scopes

see also #2304

@kilograham kilograham added this to the 2.2.0 milestone Apr 9, 2025
@kilograham
Copy link
Contributor

note also, that anything that affects the compiler choice (which many of the above do) are not really mutable as CMake doesn't like changing them in an existing build directory (we recently fixed an issue where the SDK didn't complain if you tried)

@recursivenomad
Copy link
Contributor Author

Awesome - great to know this is already on your radar. I wouldn't be familiar with deciding which caching is necessary regarding scope, but let me know if there's any ways I can help 👍

@lurch lurch added the build label Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants