You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 configurationif (NOTPICO_BOARD)
set(PICO_BOARDpico2)
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 👍
The text was updated successfully, but these errors were encountered:
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)
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 👍
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:
Upon a surface-level search (regex
set\(PICO_.*CACHE
), the following variables are affected:PICO_BOARD
PICO_BOARD_HEADER_DIRS
PICO_CMAKE_PRELOAD_PLATFORM_FILE
(twice)PICO_DEFAULT_BOOT_STAGE2
(also rp2350)PICO_DEFAULT_BOOT_STAGE2_FILE
(also rp2350)PICO_GCC_TRIPLE
PICO_NO_HARDWARE
(also in on_device.cmake)PICO_ON_DEVICE
(also in on_device.cmake)PICO_PLATFORM
PICO_TOOLCHAIN_PATH
(also in find_compiler.cmake)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 👍
The text was updated successfully, but these errors were encountered: