With RISC-V being a relatively young toolchain, a lot of inconsistencies
between different toolchains are to be found that differ in the target
triple and the flags supported. This build system performs run-time
tests to detect the toolchain and supported flags.
With `BUILD_IN_DOCKER=1` issues arise, as this checks are performed
outside of the docker container. However, the host may have no RISC-V
toolchain installed or a different toolchain, so there is little reason
in performing this detection then. Instead, a hard coded target triple
and supported flags are provided when using `BUILD_IN_DOCKER=1`.
Makefiles don't do comments, so these were forwarded into the variable.
*Most* users would expand the arguments to a shell where it'd be
ignored, but not all of them.
Contributes-To: https://github.com/RIOT-OS/RIOT/pull/18489
(This is also where the one version that is added here was removed).
The board definition of the `nrf52dk` was likely created for some clone
board. However, an official board name nRF52 DK provided by Nordic
also exists. This resulted in previous contributors in confusing this
with the official board and "fixing" the board definition to match
the nRF52 DK board.
Or maybe it always has been meant to be the official board and someone
just added a wrong image to it.
In either case, this brings the documentation back in alignment with
the code by replacing references to some random clone board and the
image of the random clone board with those to/of the official Nordic
nRF52 DK board.
This will allow more components to build on 1.64 stable, and contains a
fix relevant for https://github.com/RIOT-OS/RIOT/pull/18619.
CoAP modules are held back as they appear to need an even newer nightly
than in the current riotdocker to build without feature declarations.
In c95e8553ef the shell output of the
heap command was changed and no longer matched the expectation of the
test script. This adapts the test to again match the output.
If `AVRDUDE_PROGRAMMER` is already set to a programmer that is also
capable of debugging, we can assume that typically the user will want
to use the same hardware for debugging. Thus, let `AVR_DEBUGDEVICE`
default to the matching hardware.
