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

New issue

Open

opened 2025-04-09 12:34:37 -05:00 by recursivenomad · 3 comments

recursivenomad commented

2025-04-09 12:34:37 -05:00

(Migrated from github.com)

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:

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 👍

Some user-facing CMake variables (ie. the variables in [this table](https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf#cmake-config-variables) 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: ```cmake # 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: - [`PICO_BOARD`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/pico_pre_load_platform.cmake#L55) - [`PICO_BOARD_HEADER_DIRS`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/generic_board.cmake#L9) - [`PICO_CMAKE_PRELOAD_PLATFORM_FILE`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/pico_pre_load_platform.cmake#L128) ([twice](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/pico_pre_load_platform.cmake#L135)) - [`PICO_DEFAULT_BOOT_STAGE2`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2040/boot_stage2/CMakeLists.txt#L21) (also [rp2350](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2350/boot_stage2/CMakeLists.txt#L21)) - [`PICO_DEFAULT_BOOT_STAGE2_FILE`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2040/boot_stage2/CMakeLists.txt#L9) (also [rp2350](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2350/boot_stage2/CMakeLists.txt#L9)) - [`PICO_GCC_TRIPLE`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/preload/toolchains/util/pico_arm_gcc_common.cmake#L21) - [`PICO_NO_HARDWARE`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/cmake/no_hardware.cmake#L25) (also in [on_device.cmake](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/cmake/on_device.cmake#L91)) - [`PICO_ON_DEVICE`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/cmake/no_hardware.cmake#L26) (also in [on_device.cmake](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/cmake/on_device.cmake#L94)) - [`PICO_PLATFORM`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/pico_pre_load_platform.cmake#L124) - [`PICO_TOOLCHAIN_PATH`](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/pico_pre_load_toolchain.cmake#L2) (also in [find_compiler.cmake](https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/cmake/preload/toolchains/util/find_compiler.cmake#L27)) 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 commented

2025-04-09 15:42:45 -05:00

(Migrated from github.com)

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

see also #2304

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

kilograham commented

2025-04-09 15:43:54 -05:00

(Migrated from github.com)

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 commented

2025-04-09 17:41:13 -05:00

(Migrated from github.com)

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 👍