On Fri, 17 Apr 2015 17:07:55 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> 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. i agree. make them // FIXME: XXX: blah whatever comments. not #warnings. definitely before release. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
