-
• #2
Ahh - so
NO_COMPILE=1
is that something you'd added for your builds?I guess ideally if you want something other than a binary you'd have a build target, so
... make myfiles
But in this case it's because normally nRF52 code needs a bootloader to create a usable hex file. If you add
DFU_UPDATE_BUILD=1
to it, it'll try and create an update package which doesn't require the bootloader -
• #3
NO_COMPILE is in make file for some years now.
It was added by me to have an easy method to get wrapperfiles only.
See lines 820-823 in make file (on github) .
Its used to create a UI to support blacklist handling
I checked DFU_UPDATE_BUILD and it works fine. Thanks for this hint.BTW, there is a break in handling of WRAPPERSOURCES. entrys are all relative, only tensorflow is absolute. Is there a special reason for that, or is it grown the way it is ?
...... src/jswrap_waveform.c libs/compression/jswrap_heatshrink.c libs/math/jswrap_math.c libs/graphics/jswrap_graphics.c libs/graphics/jswrap_terminal.c libs/bluetooth/jswrap_bluetooth.c /home/nodejs/efeu/espruino/EspruinoRelease/libs/tensorflow/jswrap_tensorflow.c
-
• #4
I know it's pain to change, but are you ok with me adding this to the end of Makefile:
wrappersources: $(info WRAPPERSOURCES=$(WRAPPERSOURCES))
and then you can do
make wrappersources
instead ofNO_COMPILE=1 make
? Should be the same, but it just seems like it'd be a bit tidier and easier to maintain.Ahh, interesting that tensorflow isn't relative! Yes, I recently changed to relative paths because when assertions were built into binaries they used to contain the entire path previously - which didn't seem great and also wasted a bunch of space
-
• #5
I don't have problems with your change for wrappersources.
Pretty sure, nobody else uses this up to now ;-)
Just added the lines you recommended and removed ifdef NO_COMPILE in my local copy and it works as expected. -
• #6
Thanks! I just pushed the changes :)
After starting make
I get this again and again
Running same with ESPRUINOBOARD runs fine
Running same with MDBT42Q fails with same message
Everything runs on RASPBERRY with gcc-arm-none-eabi-9-2020-q2-update
Any idea what I've to fix ?