Hello. On 07/15/2013 01:34 PM, Stefan Schmidt wrote: > On 07/15/2013 02:19 AM, Cedric BAIL wrote: > >> I would be more for disabling the build of this example at this stage. > > Instead of disabling example they should just get reverted to the state > before the eo api change and kept working like this.
I did a bit of digging on this. Reverting my patch breaks make examples like this: ecore_idler_example.c:109:17: error: ‘ECORE_IDLER_CLASS’ undeclared (first use in this function) The usage of ECORE_IDLER_CLASS is like this since the efl merge. Means before any change of the Eo headers coming in. Which in turn makes this a regression in the API we are offering. An application that might used that with 1.7 would not longer be able to use it with 1.8. Well, it could enable the flag to get the Eo api but that is something we don't want. regards Stefan Schmidt ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
