make for Banglejs problem with bootloader

[espruino-discuss3]

Posted at 2020-11-30 by JumJum

After starting make

NO_COMPILE=1 BOARD=BANGLEJS make

I get this again and again

make: *** No rule to make target 'bootloader_espruino_2v08_banglejs.elf', needed by 'bootloader_espruino_2v08_banglejs.app_hex'.  Stop.

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 ?

[espruino-discuss3]

Posted at 2020-11-30 by @gfwilliams

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

---

Posted at 2020-11-30 by JumJum

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

---

Posted at 2020-11-30 by @gfwilliams

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 of NO_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

---

Posted at 2020-11-30 by JumJum

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.

---

Posted at 2020-11-30 by @gfwilliams

Thanks! I just pushed the changes :)