On 20/04/15 09:42, Stefan Schmidt wrote: > Hello. > > On 17/04/15 18:07, Tom Hacohen wrote: >> 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. >> " > > Agreed. Make them a FIXME in the code or a phab issue depending on what > you prefer but not a #warning. > > Also I would like to see stub functions only added if there is a > technical need for it (e.g. callback) but not as a reminder for things > to do.
Yup, I completely agree. Especially since Eo already handles it better/the same. There's really no need. I removed the #warning directives from the EFL. Next stop is E. -- 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
