crownstone / bluenet

Bluenet is the in-house firmware on Crownstone hardware. Functions: switching, dimming, energy monitoring, presence detection, indoor localization, switchcraft.
https://crownstone.rocks
91 stars 62 forks source link

Propagation of "undefining" a config value #74

Closed mrquincle closed 3 years ago

mrquincle commented 5 years ago

The configuration values are read through cmake and propagated as -DNAME:STRING=VALUE arguments to the target cmake. This is done both as CMAKE_ARGS and CMAKE_CACHE_ARGS. This works, although it's not pretty.

One thing that does not work is when a previously defined config value gets commented out by the user. In this case the cmake cache will not be refreshed. The old value will still be present.

This is in particular annoying when first working with two boards (with both GDB_PORT and SERIAL_NUM set for the gdb debugger resp. jlink programmer), and then working with one board where you want to remove both macros because it should work with any jlink.

Implementation wise, if particular values are not set, e.g. GDB_PORT, we should call UNSET with the CACHE option.

mrquincle commented 4 years ago

The actual solution is not to put those variables in the cache to start with. When cmake is run again it is fine that those are forgotten.

Everything that is worth to "remember" we have in the configuration file. That can be seen as our actual cache. In e.g. https://github.com/crownstone/bluenet/commit/5053902e5f98253abbca80c0bc93c285695e9a6d CONFIG_DIR and BOARD_TARGET are set only when they are not defined and they are never written to cache.

For now we have kept CMAKE_BUILD_TYPE in the cache. Running cmake again without this parameter will not make it switch from debug to release or to any other build type.

mrquincle commented 3 years ago

This has to be used at runtime. For e.g. changing the GDB_PORT setting there should be no recompilation whatsoever. This is implemented in https://github.com/crownstone/bluenet/commit/081a098b70406f704b07d50eaa284afe572e8b09.

mrquincle commented 3 years ago

There are probably still a few too many compiler flags, but the above has been solved through reading those variables at runtime.

The flags that are still used now:

-DBEARER_ACTION_TIMER_INDEX=3 -DBLE_STACK_SUPPORT_REQD -DBLUETOOTH_NAME=crwn -DBOARD_PCA10040 -DBUILD_CLOSEST_CROWNSTONE_TRACKER=0 -DBUILD_MESHING=1 -DBUILD_MICROAPP_SUPPORT=1 -DBUILD_RSSI_DATA_TRACKER=0 -DCONFIG_APP_IN_CORE -DCS_SERIAL_BOOTLOADER_NRF_LOG_ENABLED=0 -DCS_SERIAL_NRF_LOG_ENABLED=0 -DCS_UART_BINARY_PROTOCOL_ENABLED=0 -DDEBUG -DDEBUG_NRF -DFLOAT_ABI_HARD -DMBEDTLS_CONFIG_FILE=\"nrf_crypto_mbedtls_config.h\" -DNORDIC_SDK_VERSION=15 -DNRF52_PAN_74 -DNRF5_DIR=/home/anne/workspace/bluenet/tools/nrf5_sdk -DNRF_CRYPTO_MAX_INSTANCE_COUNT=1 -DNRF_SD_BLE_API_VERSION=6 -DS132 -DSERIAL_VERBOSITY=SERIAL_INFO -DSOFTDEVICE=s132_nrf52_6.1.1 -DSOFTDEVICE_MAJOR=6 -DSOFTDEVICE_MINOR=1 -DSOFTDEVICE_PRESENT -DSOFTDEVICE_SERIES=132 -DSWI_DISABLE0 -DUICR_BOARD_INDEX=1 -DUICR_DFU_INDEX=0 -DUSE_APP_CONFIG -DUSING_FUNC -DnRF52832_xxAA -DuECC_ENABLE_VLI_API=0 -DuECC_OPTIMIZATION_LEVEL=3 -DuECC_SQUARE_FUNC=0 -DuECC_SUPPORT_COMPRESSED_POINT=0 -DuECC_VLI_NATIVE_LITTLE_ENDIAN=1

These can be removed one by one over the course of time.