One thing I dislike about AST_DEVMODE is that changing it requires rerunning ./configure. I feel ./configure should be restricted as much as possible to checking dependencies. Any build configuration that is not directly enabled/disabled by an external dependency should be in menuselect.
If we are going to make it so TEST_FRAMEWORK doesn't enable AO2_DEBUG, I think we should allow Bamboo to run without AO2_DEBUG once. This way if any tests actually require it we can update dependencies. I'm not sure how I feel about AO2_DEBUG being combined with REF_DEBUG. AO2_DEBUG doesn't appear to add much overhead, but REF_DEBUG adds significant overhead through output to the refs log. I'm not sure someone who specifically wants AO2_DEBUG would want REF_DEBUG. Especially since REF_DEBUG can change timing and that could change results. On Mon, Jun 9, 2014 at 12:46 PM, Matthew Jordan <mjor...@digium.com> wrote: > On Sun, Jun 8, 2014 at 10:03 AM, George Joseph > <george.jos...@fairview5.com> wrote: > > Right now, the non-ref debugging code in astobj2 is triggered by a mix of > > AST_DEVMODE and AO2_DEBUG and both get set if you want to run the test > > framework. I've noticed though that the inclusion of the debugging code > can > > actually hide problems as well as highlight them, especially related to > > performance and locking. Case in point: Try running 'test execute > > category /main/astobj2 name thrash' with REF_DEBUG turned on and off. > While > > the test passes both ways, the timing is significantly different (and not > > what you'd expect). Luckily, you can turn REF_DEBUG on and off from > > menuselect. > > > > To provide a little more flexibility and visibility, I'd like to propose > the > > following... > > > > 1. Change astobj2 so the non-ref debugging code is dependent on > AO2_DEBUG > > solely instead of the mix of AST_DEVMODE and AO2_DEBUG. (REF_DEBUG would > > remain as is) > > Having two different 'dev' or 'debug' compilation flags is confusing. > I'd be happy with having them collapsed down to one. > > > 2. Remove the code that automatically sets AO2_DEBUG if TEST_FRAMEWORK > is > > defined. > > Richard may want to chime in on this, since I'm pretty sure that was a > change he initiated. > > Personally, I think it is okay if they are decoupled. We can always > enable AO2_DEBUG from menuselect in Bamboo build plans, and I'm not > aware of any Asterisk Test Suite functionality that explicitly relies > on AO2_DEBUG being defined. > > > 3. Add AO2_DEBUG to the menuselect extended compiler flags right next to > > REF_DEBUG. > > I'm okay with this too... although is there a reason why REF_DEBUG and > AO2_DEBUG shouldn't be combined? Do they absolutely have to be > separate compilation flags? > > > This way you can run the test framework in either production or debugging > > mode. The code change to do this is trivial but I thought I'd run it by > you > > guys first. > > > > Thoughts? > > > -- > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
