On Fri, 12 Feb 2010 12:34:33 +0100 Christian Lippka <[email protected]> wrote:
> So you see OSL_ASSERTS from your code, but you never see asserts from > code that your code uses. Or things you break with your code in other > places. Im covering very broad ranges of modules with DEBUG=true, not just the module were I changed code. > Can you elaborate on the issues that bother you? Various little annoyances, each not taking long to debug, but those are adding up. > And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. Which is a bug. DBG_ASSERT should be killed if favor of OSL_ASSERT anyway, or is there any valid use for having those two? > Assertions are different to build breakers enforced by the changes for > warning free code. You can very easy verify that you have not > introduced any compiler warning with your changing by simply build > the complete office (yes not 100% I know, but you can be very sure). > > But you can never be 100% sure that you didn't introduced assertions > since you can't check every code path there is that may be affected > by your changes. Therefore assertions will pop up in the master and > an abort will render non pro unusable so people will stop introducing > them. Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Assertions should be visible enough to get reported and rare enough to allow usual testing and development on the nonpro builds. Best Regards, Bjoern --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
