Should There Be Distinct Debug/Release Builds?

Development Testing
1

Preserving for debug build only, that is typical for having bugs that are not reproducable in debug builds. Not in favor for such.

2

  • It would not be feasible to force all user scenarios to use all debug instrumentation. Some instrumentation causes big performance hits, but that is critical to keeping the system working.

  • I'm not going to delete all debug instrumentation just for the sake of not having different builds.

  • There's no track record of bad bugs that have resulted in this project from over-reliance on debug instrumentation. Quite the contrary, there's a track record of really slick mechanics actually working.

While some people may not know what they're doing, I do (most of the time). So there will continue to be instrumentation that is used for my purposes to keep the code doing cool things.

I will say that if I sense there is a potential that a release build variant behavior isn't getting tested in the debug build, I make it semi-random to run both ways. That's what the SPORADICALLY() macro is for:

#if defined(NDEBUG) || !defined(DEBUG_COUNT_TICKS)
    #define SPORADICALLY(modulus) \
        false
#else
    #define SPORADICALLY(modulus) \
        (TG_Tick % modulus == 0)
#endif

Because it's driven by the interpreter tick count, it will reproduce taking the alternate behavior sometimes.

1 Like
3

I know you are aware of what you are doing.
Very happy with all those efforts!
But I remember some occasions where I had my program crash where the debug behaved very well. That really is something that can drive you mad.
Maybe one build is enough to maintain though. Else those will diverge as well. :-/