Debug / Profile / Release

edited September 2014 in General discussions
A quick question on the three different build configuration types. What might seem obvious is tripping me up.

Building orx gives us an orxd, orxp, and orx libraries.

Debug is assumed to be the one that outputs debug messages, and orxLOG lines.

Profile is the one that shows profile information if the following is added to the config:
[Render]
ShowProfiler = true

Release is for a compile without internal debug code (faster) and smaller executable size.

My confusion centres around orxLOG. Should the release build not allow the output of orxLOG messages or any logging at all? I can't find any posts or documentation that talks about the differences in any detail.

Comments

  • edited September 2014
    You're right, there should probably be more info about those somewhere in the wiki.

    You got the 3 configurations right, so let's get into the logging details.

    When it comes to log outputs, everything is handled by the orxDebug module.
    This module is controlled both by levels (that filters what will get printed) and by flags (that determine where to output the logs and in which formats).

    Flags can be accessed using the macros orxDEBUG_SET_FLAGS & orxDEBUG_GET_FLAGS. They work in any configuration.

    Levels can be accessed using the macros orxDEBUG_ENABLE_LEVEL & orxDEBUG_IS_LEVEL_ENABLED. They also work in all the configurations.

    Among all the levels, there's one special one called orxDEBUG_LEVEL_LOG. When orx is allowed to output to the terminal, that level is sent to stdout (and to its own *.log file), whereas all the other levels are sent to stderr (and to a *-debug.log file).

    And that's where come the differences. Those are wrapped in convenience macros.
    You're mostly familiar with orxLOG() but there are different flavors as well that will modify the flags before a call, such as orxLOG_TERMINAL(), orxLOG_FILE() and orxLOG_CONSOLE() and hopefully their names should be explicit.
    Those macros all use the orxDEBUG_LEVEL_LOG level.

    However, internally, all the debug checks are then printed using orxDEBUG_PRINT() with their respective level (orxDEBUG_LEVEL_SYSTEM, orxDEBUG_LEVEL_DISPLAY, etc...). That macro is only active in debug configuration and empty in all other configurations.

    So basically: orxLOG() -> always work, unless the user deactivates orxDEBUG_LEVEL_LOG manually and orxDEBUG_PRINT() -> only work in debug, no matter what.

    If a user wants more fine control, he/she can directly call _orxDebug_Log() which is the actual function called by all the macros.

    Hope that clarify the whole situation a bit. Don't hesitate if you have any other questions.
  • edited September 2014
    Excellent writeup, thanks so much!
  • edited September 2014
    This snippet serves pretty well if anyone is interested:
    orxBOOL isRelease = orxDEBUG_IS_LEVEL_ENABLED(orxDEBUG_LEVEL_SYSTEM);
    	
    if (isRelease == orxFALSE){
        orxDEBUG_ENABLE_LEVEL(orxDEBUG_LEVEL_LOG, orxFALSE);
    }
    

    So when my code is littered with orxLOG() commands, and I want to send out a release that doesn't show my log messages without removing all my orxLOG lines.
  • edited September 2014
    This version should also work, without making assumption based on enabled debug levels:
    #ifndef __orxDEBUG__
    
    orxDEBUG_ENABLE_LEVEL(orxDEBUG_LEVEL_LOG, orxFALSE);
    
    #endif // __orxDEBUG__
    

    Or you can always use your own define, of course.
  • edited September 2014
    Oh. Yes I like that.
Sign In or Register to comment.