Build issue getting the microbit_version_string in veraddr.txt and adduicr.py parsing it

[microbit-carlos]

@microbit-mark and I are having the following error during build:

[325/325] Linking CXX executable source/microbit-micropython
tools/adduicr.py build/bbc-microbit-classic-gcc-nosd/source/microbit-micropython.hex $(cat build/veraddr.txt) -o build/firmware.hex
usage: adduicr.py [-h] [-o OUTPUT] firmware address
adduicr.py: error: argument address: invalid <lambda> value: '0x'
make: *** [build/firmware.hex] Error 2

The issue is that the build/veraddr.txt file created on this step is not working as expected: https://github.com/bbcmicrobit/micropython/blob/a92ca9b1f907c07a01116b0eb464ca4743a28bf1/Makefile#L25-L26

The resulting tex file:

-n 0x
0003702d

When it should just be 0x0003702d.

[microbit-carlos]

So it looks like the echo command used in our environment (we are both using macOS Big Sur) is not taking the -n flag and printing everything after the "@echo word.

https://github.com/bbcmicrobit/micropython/blob/a92ca9b1f907c07a01116b0eb464ca4743a28bf1/Makefile#L25

Just to confirm, the problem is not objdump as that prints the address without an extra blank line:

$ objdump -x build/bbc-microbit-classic-gcc-nosd/source/microbit-micropython | grep microbit_version_string | cut -f 1 -d' '
0002f6d0
$ arm-none-eabi-objdump -x build/bbc-microbit-classic-gcc-nosd/source/microbit-micropython | grep microbit_version_string | cut -f 1 -d' '
0002f6d0

[microbit-carlos]

This looks relevant: https://stackoverflow.com/questions/11675070/makefile-echo-n-not-working

@printf and @/bin/echo -n both work, not sure if one should be better than the other. I assume they would both work on macOS/Linux, and probably on Windows if they have Make installed?

I think I prefer @printf to leave the system resolve the programme location automatically? (echo and printf should be shell built-ins, but they are likely .exe files on Windows?), rather than have the specific /bin/echo, although I assume something like MinGW should resolve that correctly anyway.

[dpgeorge]

Should be fixed by dc92faf91be4cdf74130ec9144a5e5ba02d3836d (echo is no longer used).