By default if IoT-LAB Cli Tools V3 is used then BINFILE is used to
flash on IoT-LAB. But BINFILE is not built by default when RIOT_CI_BUILD
is set as a ci optimization.
But since before IOTLAB_NODE was not passed to docker when building it
did not know that it should BUILD BINFILE as well, which led to failures
if doing:
$ IOTLAB_NODE=iotlab-m3.grenoble.iot-lab.info BOARD=iotlab-m3 \
RIOT_CI_BUILD=1 BUILD_IN_DOCKER=1 make -C examples/hello-world/ flash
But if IOTLAB_NODE is passed at is checks for IoT-LAB cli Tools also
happen in the docker container which leads to a make error since those
are not present in docker.
Therefore add BINFILE to BUILD_FILES if RIOT_CI_BUILD is set, but unset
IOTLAB_NODE once INSIDE_DOCKER.
The check for `newlib-nano` assumes that a toolchain which provides `newlib-nano` provides both the normal version and the nano version of the `newlib`.The nano version of `newlib.h` is therefore stored in its own include directory. This is the case for toolchains which allow to use both the normal and the nano version, e.g. for ARM and RISC-V.
However, if the toolchain provides `newlib_nano` but only allows the use of the nano version, it will only have the nano version of `newlib.h` and no separate directory for it, e.g. for ESP32.
To still be able to use such toolchains with `newlib_nano`, the check is changed so that the setting of the `-isystem` option depends on the existence of the separate directory.
Without passing this through, any crate downloads would go to the
container's image's scratch space, to be re-downloaded for each build,
and with new time stamps that cause compilation to start anew as well.
A couple of `stdio` backend implementations allow to check for the number of available bytes for reading before the blocking `stdio_read` is called. This helps to implement non-blocking functionalities while waiting for `stdin`.
For RISC-V and Cortex-M-not-3, triples are known and have worked in some
configuration, but do not work at the moment and stay disabled until the
reference platforms (native, M3) have been established well.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
The pseudomodules used by the PCF7857x driver are correctly defined by `Makfefile.include` of the driver. However, by mistake they were left in `makefiles/pseudomodules.mk` when the very old PR was rebased to the current master. That is, they were only leftovers that have been overseen after rebasing an squashing dozens of fixup commits.
