Propogate changed pico_cmake_set_default values to the compilation #2034
No reviewers
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk!2034
Loading…
Reference in a new issue
No description provided.
Delete branch "pico-board-cmake-overrides"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently, if you pass
-DPICO_FLASH_SIZE_BYTES="(2 * 1024 * 1024)"to CMake, that modified flash size is only used in CMake (when generating the linker script) and doesn't propogate through to the compilation. To set it for the compilation you need to add a separatetarget_compile_definitions(my_exe INTERFACE PICO_FLASH_SIZE_BYTES=${PICO_FLASH_SIZE_BYTES})to your CMakeLists.txt file.This PR changes this behaviour, so
pico_cmake_set_defaultvalues that have been overridden (eg with-DPICO_...orset(PICO_...)will propogate through to the compilation. If the default value isn't modified then the behaviour is not changed, and you can still usetarget_compile_definitionsto set the values for compilation only.Adds a PICO_BOARD_CMAKE_OVERRIDES common scope variable, to contain any pico_cmake_set_default CMake variables which have been overwritten. This is populated when reading the board header, and then read when compiling
pico_base_headers.Also add
pico_cmake_set_default PICO_RP2350_A2_SUPPORTED = 1to board headers to enable/disable the E10 abs-block fix, and modifycheck_board_header.pyto support this. This allows specifying-DPICO_RP2350_A2_SUPPORTED=0to CMake to prevent the creation of an abs_block, for example this could be used when you are not planning on dragging & dropping your UF2 into partition tables.@will-v-pi can you be a bit more precise in the comment above "if you compile with... is only used in the CMake" doesn't make any sense (to me)... perhaps you mean "if you pass -Dxxx to CMake"
So my limited CMake knowledge means that I don't fully understand all of this, but it seems to me like there are now a couple of settings (
PICO_FLASH_SIZE_BYTESandPICO_RP2350_A2_SUPPORTED) which have to be set to the same value in both the "cmake world" (viapico_cmake_set_default) and also the "compiler world" (via#define). Is there any way we could come up with some generic mechanism, rather than needing e.g.in the header-file for every board that uses the RP2350? Or is this already the "best" way of handling this? (I guess my concern is how badly would "things go wrong" if the "cmake world" sees a different value to the "compiler world"?)
@will-v-pi I just cloned this branch and tried running
tools/check_all_board_headers.shlocally, and it seems that you somehow missed out adding theline to the
hellbender_0001.handpico2_w.hheader files!Also, here's a small tweak to the
tools/check_board_header.py(feel free to include it or ignore it as you see fit) :Yes, that's what I meant - I've updated the comment
Personally, I think this is the "best" way of handling things - everything that directly affects the compilation is in normal pre-processor
#defines, and then the things that affect the CMake configuration are in comments. The board checking scripts are available to check they match up, but even if the don't match it won't cause any major problems.It would be fine for the "CMake World" to see a different value to the "compiler world" - for example for
PICO_FLASH_SIZE_BYTESit just means that the linker script will have one flash size, and functions using the flash size (egflash_range_erase) will assert values are in range based on a different size. This could mean that when linking my code it only uses 2MB of flash, but when erasing I can erase all 4MB of the flash, which could be a valid use case.Brilliant, thanks for reassuring my paranoid little brain 🧠 😂
I'm still not happy with what I originally did here, and was worried about proliferation of requirements for more
// pico_cmake_setbut with the validation script changes, we're at least a little better off.Also proliferating the settings override one way (Cmake->compile_defs) is a good improvement