build option RELEASE=1

Posted on
  • Can someone please explain the build option RELEASE=1 ?

    found those lines in Makefile:

    # RELEASE=1 # Force release-style compile (no asserts, etc)
    ifdef RELEASE
    # force no asserts to be compiled in
    DEFINES += -DNO_ASSERT -DRELEASE
    endif

    make and sdk 2.0 with USE_NET=1 USE_TELNET=1 USE_GRAPHICS=1 USE_CRYPTO=0 and RELEASE=1
    user1.bin uses 473876 bytes of 479232 available

    make and same setting but without RELEASE=1
    ** user1.bin uses 489364 bytes of 479232 available
    espruino_esp8266_user1.bin too big!

  • My guess would the the compilation flag "-DNO_ASSERT" is the key component. If we look in "jsutils.h" we find that this flag is used to control the implementation of "assert()" statements in the source code.

    An assert() statement is a debugging/coders tool that checks the truthiness of an expression at runtime. We want to "assert that some condition is true at this point". The asserts are added by coders who have concern that some condition that they expect to be true at this point actually is ... and if not ... usually stop here and alert someone. One shouldn't use assert() statements to trap "expected" issues ... for example ... if a filename is expected to be passed to a routine and it is found to be NULL, that would most likely be checked via exception and return code ... however if we presume that an internally calculated number will never be zero ... because we "think" the logic should not allow that ... then coding:

    assert(x !=0);

    is a good programmers statement to catch errors.

    In a production/released solution, usage of "assert" statements should no longer be present. When an end user runs a program, it is meaningless to them to see:

    assert at line 1234 for file xyz.c: x!=0

    Instead we would hope they would see a nice message or a dialog and gracefull degredation of the application. Because asserts should only used during development time, they should be "removed" for a production release. However, because we don't want to go through source code and remove asserts when they might still be useful in the future, what we want is a build time flag that determines whether or not the assert() statements are included in the compiled code.

    Espruino seems to use the C definition "NO_ASSERT" to remove them. During compile, if NO_ASSERT is set, then assert() statements are "no-oped". Since an assert statement will be an "injection" of code into the source, switching off assertions ... by setting NO_ASSERT which is set when RELEASE=1 prevents the assert() statements from being inserted. No assert() statements ... smaller compiled code ... smaller resulting image size.

  • Thanks Neil, for your detailed explanation.

  • Yes - generally I run builds here with the asserts in, to catch unexpected behaviour. It makes everything slower though so I take them out for 'real' builds.

    Having said that, in the last year or so Espruino has grown so large that I'm unable to build without release on most platforms.

    Just fyi USE_CRYPTO=0 could be a bad idea - often makefiles/C files only check to see if a definition is made, not what it is. It might be that it actually has the same effect as USE_CRYPTO=1. If you don't want it, just leave out of the command line

  • I used USE_CRYPTO=
    Means without any value. At least in my case this works.

  • Yes - indeed - I do not use USE_CRYPTO=0 to disable crypto

    this is what I do:

    change a line in Makefile:

    #USE_CRYPTO=1

  • ^^^ yes, that's what I'd suggest :)

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

build option RELEASE=1

Posted by Avatar for MaBe @MaBe

Actions