Hello. On Tue, 2014-04-15 at 10:52, Tom Hacohen wrote: > On 14/04/14 11:44, Stefan Schmidt wrote: > > Hello. > > > > On Sun, 2014-04-13 at 12:53, Tom Hacohen wrote: > >> > >> I figure we are doing this to get higher coverage values/more real/catch > >> some tiny more issues, but I'm not sure it's worth it. Might be a good idea > >> to make it sane (default, or at least info, not debug). I know, things > >> might break without us noticing in some debug paths, but it's not worth. > > > > Eveything we don't run regulary will bitrot. E.g. I just tried to run > > make examples in efl triggered due to T1161 and I get a different > > error with missing evas_table.eo.legacy.h which basically means we > > will ahve at leats two problem in make examples right now. > > > > This should be no blame but showing that everything that gets not run > > at least a day will bitrot. > > > > If you think the debug paths are not worth to run them we should go > > ahead and remove them instead of having code nobody uses. > > > >> A better idea, would maybe, if we really want it, to have a "make > >> debug-coverage" that can be used on the buildbot, I don't know. Though it's > >> really annoying for clients, and they should, if they wanna test for > >> coverage in that case, just set the env var. > >> > >> Any thoughts? > > > > Why make it more complicated? I see two things we can do here to fix > > the problems we currently have: > > > > 1) Produce less noise in eolian with debug enabled. Daniel and his > > team are already looking into this. > > > > 2) Remove noisy debug in other areas and remove debug paths if they > > are worthless. > > > > As a band aid until 1) is done I removed the debug flag for coverage > > builds. > > > > regards > > Stefan Schmidt > > > > I think Daniel fixed it. Have you re-enabled debug?
Yes, he told me. I just haven't seen his change before pushed mine to have a workign build. Will revert my band aid later today and see how the nightly goes. > Anyhow, the problem is that some debug info is useful for devs of > things, but not for users/common paths. > > Maybe we should have a new class called dev debug, which is just for the > debuggers of the components. Compiled out when not doing dev builds, and > even with coverage it's off by default (i.e will only start from the > current debug, user-debug). To me this sound like another level where everyone has different understandings for. Which is one of the problems we have with all our logging. Developer tend to rate debug infos on their own code which they are working on higher than other parts of the code they care less about. :) We have different log daomians and log level for all this. Its just that we are using them all very differently. I'm not conviced that a dev-debug would help here but I'm also not against it. This whole debugging levels is a can of worms I did not want to open. :) regards Stefan Schmidt ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
