Closed mrquincle closed 3 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.
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.
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.
The configuration values are read through
cmake
and propagated as-DNAME:STRING=VALUE
arguments to the targetcmake
. This is done both asCMAKE_ARGS
andCMAKE_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
andSERIAL_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 callUNSET
with theCACHE
option.