Hey, As you guys may have noticed, a few people have started using the compiler #warning directive as their public TODO. I guess it makes sense, because it's distributed and safer than a piece of paper. However it's really bad, and is polluting our compiler output.
Just to give one example (out of a few in e and efl): src/lib/ector/cairo/ector_renderer_cairo_shape.c:228:2: warning: #warning "fill for a shape object is unhandled at this moment in cairo backend." [-Wcpp] #warning "fill for a shape object is unhandled at this moment in cairo backend. " As a fellow developer of the EFL, all I read is: "I decided to push a half-baked feature. I couldn't be bothered to finish it, but here it is. Someone please get annoyed enough to finish my work for me.". It's very simple. If this feature is essential, the patch should not have gone in, and should have waited until *READY* before pushed. If the feature is non-essential, why pollute my output? You have a todo item? Put it in your todo. You absolutely feel like adding a stub function? or is it a code path that can't be avoided but just not there yet (and again, non-essential), add a runtime eina error with some documentation notice, and possibly a FIXME in code just to help find the exact place. You think no one looks at FIXMEs? Well, you are correct in that people usually don't scan for FIXMEs to fix, but it still helps to have them there to point to the offending piece of code. Either way, you should have your own *private* todo file (or however you track the things you wanna do) in order to remember to do tasks obviously no one else will. Writing a big noticeable message (we compile warnings free apart of those, so it is noticeable) that only applies to yourself is egoistic, and if you expect other people will pick up your slack because you annoy them enough with these warnings, it's even worse. If you'd like help, in addition to your personal TODO, maybe also open a critical phab ticket? All of those are far better and less annoying ways to solving this. I'd like to get rid of these warnings before the release, so when our packagers compile the EFL, they don't get these annoying warnings. -- Tom. ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
