Whilst working on porting I stumbled upon an interesting discovery, I am however not sure if it should be classified as a bug, or if it is intended behaviour (“should not harm others on mass build”):
I had to add a new board to the tplink-safeloader from firmware-utils, I did a typo there which lead to the build not running as expected.
However, make world did not report any errors, but the binaries where missing from the targetsfolder. Upon running with V=S I found an error message indicating "sysupgrade is greater than available space” - but there was no file, going further up I found a message from tplink-safeloaderreading Board XXX not found: Success
Is it intended, that this does not cause the build to error out?
I know, this ain’t a real or helpful error report. I could provide some more details, if this is considered a bug.
I suspect the build doesn't want to break if tplink-safeloader fails due to the image getting too big to fit the flash partitions, but I could see an argument for making it break for other failures.
IMO, the bigger problem here is the build error message confidently asserting the problem to be a space issue, when that's not the only potential reason for the failure.
I guess it is a little confusing because there are max size checks in both tplink-safeloader and the build scripts. You're right that the build check is not specifically making assumptions about tplink-safeloader, it'll report image too big if the image doesn't exist because it doesn't check for that. However, I still say it's a confusing error message that is probably not as intended for this case.
Anyway, I still say the build probably should not stop dead for any case of image not generated, because one of the reasons the image would not be generated is a size check in the tool that makes it.